Tech Talks Daily

What if your website already supports post-quantum cryptography, but nobody inside your organization knows how, why, or which provider controls it?

I speak with David Warburton, Director of F5 Labs Threat Research, about new F5 research examining post-quantum cryptography across the world's top one million websites. According to the research discussed in our conversation, 54% now support PQC. It is an encouraging sign that preparations for future quantum threats are entering mainstream infrastructure.

That figure is also easy to misread. David explains that much of the adoption comes from cloud and CDN providers enabling hybrid post-quantum protection for their customers. A smaller business could therefore appear better prepared than a large enterprise simply because its provider activated the technology automatically. However, that customer may have little understanding of the chosen cipher, the protection applied elsewhere, or the dependencies created around a small number of technology companies.

David says the adoption rate looks very different when major CDN providers are removed from the data. This raises an important question about whether businesses are developing their own post-quantum security capabilities or temporarily benefiting from decisions made on their behalf.

We discuss why current deployments combine established cryptography with newer post-quantum algorithms. This hybrid approach protects compatibility while browsers, APIs, operational technology, IoT devices, and older enterprise systems catch up. It also carries performance costs through larger cryptographic material and increased network traffic. David argues that crypto agility matters because organizations need the ability to change algorithms, certificates, and encryption methods as threats develop.

The conversation also moves beyond encrypted traffic. Harvest now, decrypt later attacks involve collecting sensitive information today so it can potentially be decrypted when capable quantum computers arrive. David believes authentication and digital identity could create an even greater concern. A quantum computer able to produce valid certificates could potentially impersonate trusted websites, signed software, devices, or firmware.

Legacy infrastructure remains one of the largest barriers. F5 Labs found that roughly one in ten leading websites lacked TLS 1.3 support, preventing them from supporting current hybrid PQC connections. David also explains why Germany and France may trail countries including the US, UK, Australia, Ukraine, and Singapore, despite strong national policies. Factors include digital sovereignty concerns and the concentration of older manufacturing and operational systems.

For leaders beginning this work, David recommends speaking with suppliers, establishing internal ownership, reviewing business continuity plans, and creating a cryptographic bill of materials covering certificates, algorithms, libraries, applications, and devices.

I'd love to hear your thoughts, so does your organization know where its cryptography lives and who controls its post-quantum readiness?

How can governments and public-service organizations adopt AI quickly while protecting the people affected by their decisions?

In this episode of Tech Talks Daily, I speak with Holly Ellis, AWS Director for UK, International Organizations and Germany Public Sector Technology. Holly has worked on both sides of public-sector technology, with previous roles in local and central government before joining Amazon. She now leads teams supporting customers across education, healthcare, nonprofit organizations, local government and central government.

We discuss why public-sector technology adoption depends on a wider system of governance, procurement, regulation, culture and skills. Holly cites AWS research with Strand Partners showing that half of UK public-sector organizations identify shortages in AI and digital skills as their main adoption challenge, up from 46 percent in the prior year. Over the same period, reported AI adoption rose from 52 percent to 64 percent. Her point is simple: greater adoption creates demand for a larger number of people with deeper knowledge.

Holly also explains what responsible speed looks like when AI supports services involving education, healthcare or national institutions. Her approach is to think big, start small and scale fast, containing the effect of failure while teams build confidence. University clearing offers one example. Several universities used Amazon Connect during A-level results, with one institution handling up to three times the call volume of its previous system and confirming a four-figure number of student places in one day.

The conversation then turns to safeguards. Holly argues that leaders must define organization-wide protections while engineers remain responsible for the systems they build. Depending on the consequence, those protections may include human review, observability measures and tightly scoped permissions for AI agents. At the Ministry of Justice, AWS Transform processed 24,000 lines of code during an initial nine-hour pass and completed a second pass in two hours. Human review took about 20 hours, compared with an estimated nine months for manual modernization.

We also consider legacy technology, digital sovereignty and the difficulty of measuring AI outcomes. Holly describes sovereignty in practical terms as control, transparency and optionality. She advises leaders to define the outcomes they intend to measure before selecting initiatives, then build upon work that demonstrates the strongest returns. According to the AWS research discussed, organizations redesigning workflows and decision-making with AI reported average efficiency gains of 68 percent, compared with 40 percent among basic users.

The wider lesson is that responsible public-sector AI depends on technical choices, people, governance and evidence working together. Can public services become faster and more responsive while retaining the safeguards and public confidence they require? Listen to the conversation and share your thoughts with me.

What happens when an AI system moves beyond generating answers and begins influencing machinery, maintenance schedules, technician dispatch, and safety?

In this episode of Tech Talks Daily, I speak with Bob De Caux, Chief AI Officer at IFS, about moving industrial AI from promising pilots into dependable production deployments.

Bob explains why access to advanced models is no longer the main obstacle. Successful enterprise AI depends on understanding the processes, operational logic, metadata, and boundaries surrounding each decision. An AI system ordering a replacement bearing for a wind turbine must meet a very different standard from one generating a nursery rhyme.

We hear how IFS customer Kodiak Gas is using a digital worker to support material replenishment. According to Bob, the company projects approximately $3 million in annual return and 90,000 hours returned to technicians for higher-value work.

Our conversation also covers AI sovereignty. Bob argues that sovereignty means retaining control over data, decisions, providers, and the ability to keep operating under changing circumstances. He compares the technology layer to a duck paddling furiously beneath calm water. Models may change rapidly, while the operational application above them must remain stable, tested, and auditable.

We discuss staged autonomy as a way to earn worker confidence, beginning with manual questions, progressing to recommendations, and granting greater authority only after consistent performance. Bob also explains why agents need identities, permissions, defined roles, separation of duties, sponsors, and complete audit trails.

Accountability remains with the organization deploying the system. In an industrial environment, an agent can produce a harmful action rather than an inaccurate answer. Even after 999 successful decisions, the thousandth can carry catastrophic consequences.

Is your organization measuring AI through pilot counts, or through uptime, cost, technician capacity, turnaround time, and safety? Listen to the conversation and share your thoughts with me.

Could your organization produce a complete record of everything its AI systems accessed, sent, or shared within one business day?

In this episode of Tech Talks Daily, I welcome Tim Freestone, Chief Strategy Officer at Kiteworks, back to the podcast for his third appearance. Our conversation centers on the company's 2026 Data Security and Compliance Risk Annual Survey and the difference between buying security technology and being able to demonstrate that sensitive data is properly controlled.

According to the Kiteworks research supplied for this interview, 80 percent of surveyed organizations experienced at least one security or AI related incident during the previous 12 months. Half could not produce a complete AI data access audit record within one business day. The strongest group recorded an average readiness score of 46 out of 100, while organizations with weaker security and AI governance averaged eight. Even the higher score leaves considerable room for improvement.

Tim argues that technology spending can produce a larger version of the same exposure when a company lacks the people, ownership, and operating model needed to manage what it has purchased. Network, cloud, and infrastructure security still matter, but the business ultimately needs to understand what is happening at the data layer. Which identities can access a system? What actions can they take? Which records can they read, change, send, or share?

We discuss why this has become harder as employees create large numbers of AI agents. A company may have 1,000 people and tens of thousands of nonhuman identities, each requiring permissions and oversight. Tim describes three connected control planes covering identity, actions, and data. Together, they offer leaders a practical way to assess whether an agent can reach information it should never see or perform an action it was never meant to take.

The conversation also examines audit evidence. Tim says businesses should map regulated data types to the controls governing their use and then connect those controls with reporting. Without that connection, answering an auditor may require months of work, large consulting bills, and teams manually assembling records from disconnected systems.

Ownership remains difficult because security, compliance, infrastructure, and data governance teams often work separately. Tim's view is that the CEO must orchestrate responsibility when the board is asking AI to produce higher productivity while the same systems create new data risk. That position may feel demanding, but it exposes an issue many leadership teams still need to settle: who owns the consequences when an AI agent exposes or transforms sensitive information?

For board members, Tim offers two direct tests. Ask for a clear account of the company's data controls, then ask who is responsible for the associated risk. If those answers require a long explanation or several departments pointing at one another, the readiness score may matter less than the inability to demonstrate control.

How quickly could your organization show who or what touched sensitive data, and who would be accountable if the record were incomplete? Listen to the episode and share your thoughts.

What happens when an AI agent follows your documented process perfectly, but that process bears little resemblance to how decisions are actually made?

In this episode, I speak with Bill Wilson, Executive Head of Data and AI Solutions at NTT DATA UK&I. Bill oversees AI globally for NTT DATA's public sector work, giving him a close view of how governments are using AI while trying to manage risk, accountability, public confidence, and constrained resources.

Bill offers a refreshingly practical test for any proposed AI system: is it competent, and what is the worst thing that could go wrong? He describes this potential consequence as the system's "blast radius." An AI assistant helping somebody understand a grant application presents a very different level of risk from an agent making decisions that affect employment, justice, taxation, or access to public services.

We also discuss why companies can make a mistake before deploying their first agent. Automating an inefficient process simply allows the organization to perform the wrong work faster. Bill argues that teams should examine complete workflows, identify where several AI capabilities could produce a measurable result, and remain prepared to redesign the process as they learn.

Another major problem is tacit knowledge. Employees frequently make decisions using experience that was never written down. An agent trained solely on formal documentation may therefore understand the official process while missing how the work gets done in practice. Bill explains how targeted questions, behavioral traces, feedback, and supervised learning could capture some of that reasoning.

Public sector AI provides several useful examples. Bill discusses systems that process volumes of information beyond human capacity, emergency response work in Tennessee, and case management applications that gather information before a human reviews it. In these situations, AI can reduce administrative work and waiting times while leaving consequential decisions with people.

But human approval alone provides no guarantee. If employees lose direct experience of the work, they may eventually approve whatever the system recommends. Bill compares this with airline pilots maintaining manual flying skills and describes how known test cases can reveal when reviewers are becoming overly trusting.

For CIOs deciding which AI pilots should reach production, the advice is equally direct: choose work with measurable returns, group related use cases where their combined effect can be seen, learn from a varied set of deployments, and avoid building something a software provider is about to include in an existing product.

As AI agents gain access to external information, internal data, and operational tools, how should your organization decide what they may do alone and when a person must intervene? Listen to the conversation and share your thoughts with me.

Who carries responsibility when an AI agent begins reviewing contracts, applying regulatory rules or making commercial decisions on behalf of an organization?

In this episode of Tech Talks Daily, I speak with John Nay, founder and CEO of Norm Ai, about Agentic Law and the attempt to redesign legal work around AI agents, legal engineers and experienced attorneys. John has worked across AI, law and public policy for approximately 14 years. His early research adapted neural network methods to legal and government text before large language models became a commercial force.

The company information supplied for this episode states that Norm Ai recently raised $120 million in Series C funding at a $1.2 billion valuation, bringing total funding to over $260 million. Norm also says organizations representing over $30 trillion in assets under management use its technology for legal and compliance work. Those figures provide useful context for the scale of interest, while our conversation concentrates on how the model works and where responsibility remains human.

John describes Norm Ai as automating the first pass of legal and compliance tasks. One example involves an in house team using an agent to review communications against relevant rules before a person finalizes the decision. Another involves Norm Law receiving transaction documents, assigning the first analysis to AI agents and then presenting the output to an experienced attorney. The attorney decides what happens next, communicates with the client and supervises anything leaving the firm.

That division of labor matters because legal reasoning contains several layers. Some work can be handled through deterministic rules. Frontier models can then apply guidance and precedent to new situations. Human judgment remains responsible for high stakes advice and the review of agent output. John also stresses that the model is not making an isolated request to a generic system. Legal judgment is embedded in the way agents are designed, tested and called before live matters enter the workflow.

We discuss legal engineering as the bridge between software and professional practice. Norm's legal engineers are trained attorneys who spend much of their time building, testing and validating agents. They work with practicing lawyers, clients and AI engineers to translate preferences, policies and matter specific requirements into systems that can operate within real workflows.

Pricing is another part of the model. Norm Law prices selected matters around outcomes rather than hours. John acknowledges the limits. Some complex work can be scoped with enough confidence for a fixed price, while highly unpredictable litigation is much harder to price upfront. The opportunity is to give AI the incentive to examine additional documents and identify inconsistencies without increasing a client's bill for every human hour.

The conversation then moves to the proposed Delaware AI Company initiative. John describes it as a regulatory sandbox for a legal entity managed by an AI agent while humans remain involved in its creation and supervision. His argument is that autonomous agents will take increasingly consequential economic actions, so policymakers must decide whether those activities happen within a recognized legal order or outside it. The proposal is designed to test questions around liability, disclosure, capitalization and government oversight before any broader model is adopted.

John also believes companies deploying agents today should consider supervisory AI. If an operational agent can act faster and at greater volume than a person, a human team may be unable to inspect every decision. A second agent can evaluate the first against laws, regulations and company policies, with people retaining authority over exceptions and consequential outcomes.

Does adding a supervisory agent create stronger accountability, or does it introduce another system whose reasoning must also be tested and questioned? Listen to the episode and share your thoughts with me.

Has enterprise AI finally reached the point where impressive demonstrations are no longer enough?

In this episode, I speak with Murali Swaminathan, CTO at Freshworks, about the growing pressure on AI investments to deliver measurable business value. Murali has over 30 years of enterprise software experience, including roles at ServiceNow and CA, and now leads engineering and architecture teams at Freshworks.

Murali believes the AI hype cycle is being replaced by an accountability cycle. Buyers want to understand reliability, governance, total cost of ownership, traceability, and the return generated by every deployment. They also want the ability to audit decisions, override outcomes, and use feedback to improve performance.

Productivity alone provides an incomplete measure. Within service operations, companies can examine time to resolution, the volume of repetitive work automated, the number of issues completed without human intervention, and the quality of the employee's experience.

Murali describes the difference between service-level agreements and experience-level agreements. Resolving a ticket within two minutes means very little if the employee's problem remains. The better question is whether AI completed the workflow and restored the person's ability to work.

We also discuss why mid-market and agile enterprises provide a demanding test for AI. These companies have complex requirements but cannot absorb lengthy implementation programs, unclear pricing, or failed experiments. Murali recommends beginning with a limited process, measuring the result, establishing whether it can be repeated, and expanding only after it has proved reliable.

Architecture plays an important role. Murali argues that ease of use begins beneath the interface. Configuration-led platforms can be upgraded as new capabilities arrive, while heavily customized systems can leave companies trapped on older releases.

Autonomous service operations do not require removing people from every process. Murali uses the example of a printer incident. AI can read the ticket, classify the problem, route it to IT or facilities, and apply an automated fix when a trusted process exists. People retain responsibility for unusual, uncertain, or higher-risk decisions.

Scaling this model requires cloud infrastructure that respects regional data residency, privacy, encryption, routing, and audit requirements. AI requests and diagnostic logs must remain within the correct geographic and regulatory boundaries.

The conversation concludes with engineering skills. AI coding tools can generate software quickly, but engineers must understand architecture, usability, testing, and customer requirements. Companies also need rules determining which code can be reviewed by AI and which changes require human approval.

Is your company measuring whether AI genuinely improves service operations, or is it counting deployments and calling that progress? Listen to the episode and share your thoughts with me.

What happens when an organization writes careful AI governance policies but its infrastructure cannot enforce any of them?

In this episode of Tech Talks Daily, I speak with Sabina Anja, Chief Technologist at Broadcom within the VMware Cloud Foundation division, about the infrastructure controls required as AI agents move from generating answers to accessing data, calling APIs, modifying systems, and triggering work.

Sabina brings experience from both sides of enterprise technology. She remembers cabling networks, dealing with unstable infrastructure, and receiving those weekend calls when downtime had already upset the business. That background informs her belief that ambitious AI programs cannot succeed without stable, observable, and enforceable infrastructure beneath them.

Many organizations are repeating a familiar pattern. Business teams adopt AI services before IT has established visibility, ownership, or control. The terminology may have changed from shadow IT to shadow AI, but the management problem remains. Sabina argues that CIOs first need an inventory of agents, nonhuman identities, data access, processes, and accountable owners.

The risk becomes greater because agents behave differently from people. They operate across multiple systems at machine speed and can perform repeated actions without appreciating the wider business outcome. An agent does not need malicious intent to cause disruption. Excessive permissions, flat networks, inconsistent access rules, and years of deferred infrastructure work can give it plenty of opportunities.

Sabina recommends brokered access rather than direct access, alongside dedicated virtual machines or namespaces, microsegmentation, lateral security, east-west policy controls, and tamper-evident logging. Organizations also need to define which data an agent can view, modify, or move, especially when sovereignty and regulatory requirements apply.

One of Sabina's most memorable ideas is to treat an AI agent like a superhuman contractor. It should have a defined purpose, a named manager, a clear access specification, an activity record, and an end date. Additional permissions should be earned through evidence of reliable behavior rather than granted on the first day.

She also warns about agent debt. AI systems are developing rapidly, so an agent created today may become outdated within months. Sabina recommends assuming that many agents will expire after six to nine months rather than allowing forgotten systems and permissions to accumulate indefinitely.

For CIOs wanting an immediate test, her advice is straightforward. Create an inventory of nonhuman identities with production access. Then select one agent and examine every part of the infrastructure it attempted to reach. The question is not simply whether the application produced the expected result. Leaders should ask whether the agent entered systems, networks, or data stores that nobody expected it to access.

We also challenge the familiar claim that AI agents will take everybody's jobs. Sabina sees an opportunity to remove repetitive tasks and give technology professionals new skills, although she warns that agents may behave like teenagers armed with infrastructure permissions. They may not take your job, but they could become remarkably good at testing your patience.

I'd love to hear your thoughts. Does your organization know how many AI agents have production access and who is accountable for each one?

What does a rising cloud bill actually tell you about the value your business is creating?

Eight years after our first conversation, I welcome Kunal, co-founder and CEO of Unravel Data, back to Tech Talks Daily. We compare the data infrastructure he was optimizing during the Hadoop era with today's enterprise stacks built around Databricks, Snowflake, BigQuery, AI pipelines, and autonomous agents.

Kunal says Unravel Data has analyzed over 10 billion workloads across hundreds of enterprises. From that work, he argues that data platforms and infrastructure can account for up to 60% of cloud spending at some global businesses, while 30% to 40% of data platform spending may produce no business value. These are company claims, but they frame a problem many technology and finance leaders will recognize. The cloud bill arrives after thousands of individual engineering decisions have already been made.

We discuss where cloud waste hides, including oversized clusters, hot storage holding cold data, abandoned pipelines, inefficient queries, duplicate datasets, and development jobs consuming production-level resources. The people creating those workloads seldom see the price attached to their decisions, leaving technology leaders with an aggregated bill that explains what was purchased but not why it was needed.

AI adds another complication. Humans create workloads at human speed, while agents can generate queries, launch infrastructure, and consume tokens around the clock. An agent is designed to complete its task, not worry about whether a single query costs $5 or $5,000. Kunal argues that machine-speed consumption cannot be governed through monthly human reviews.

We also discuss the difference between cost cutting and cost optimization, why aggressive reductions can damage performance and reliability, and how FinOps must connect cost with business outcomes. Kunal explains why leaders should measure cost per pipeline, model, agent, successful run, customer report, and business result.

Finally, we consider the benefits and risks of autonomous data platform optimization. Kunal describes autonomy as a dial, with bounded, reversible, and validated actions earning wider authority as trust develops.

Does your cloud bill show healthy growth, or is expensive waste hiding behind the headline number? Share your thoughts with me.

How can an independent safety evaluation remain meaningful when the AI inside a product may change after its next update?

In this episode of Tech Talks Daily, I speak with Dr. Robert Slone, Senior Vice President, Chief Scientist, and Innovation Officer at UL Solutions. Robert has spent almost 30 years leading science, research, product development, and innovation teams. He now helps guide UL Solutions' scientific work across safety, security, and sustainability.

Many listeners will recognize the UL Mark without knowing what happens behind it. Robert explains how UL Solutions tests products to their limits, which can involve setting them on fire, finding their breaking points, inspecting manufacturing facilities, and determining whether they meet defined safety requirements.

That work began over 130 years ago when electricity was introducing unfamiliar risks. Today, the same broad question applies to artificial intelligence: how can society benefit from a new technology while understanding and managing the harm it could cause?

The need is becoming increasingly visible as AI moves into healthcare, transportation, manufacturing, financial services, infrastructure, and consumer products. Robert recalls being approached about evaluating an AI-enabled teddy bear capable of talking with children. It is a memorable example of how decisions made inside an AI model can reach directly into everyday life.

Robert organizes AI product safety around three pillars. The technical pillar considers robustness, risk management, functional safety, and whether the system performs its intended purpose. The ethical pillar includes fairness, bias, privacy, transparency, and explainability. Governance covers data management, product updates, accountability, and the complete operating life of the system.

We also discuss one of the hardest problems in AI certification. Traditional products and software can be evaluated against a defined version, but AI systems may be updated, retrained, or affected by changing data. Robert explains why meaningful safety assurance requires version-specific testing, annual reviews, disclosure of significant changes, and eventually telemetry capable of identifying problems much closer to real time.

For business leaders buying AI, the conversation provides a practical vendor checklist. Where did the training data come from? How was performance measured? What are the system's known limitations? How were privacy and bias assessed? Who takes responsibility if its behavior changes?

Independent testing cannot promise that an evolving product will remain safe forever. It can provide evidence about the version evaluated, expose gaps, establish accountability, and create a process for monitoring future changes.

What proof would you demand before allowing an AI product to influence an employee, patient, customer, or child? Listen to the episode and share your thoughts with me.