Bending Spoons has snapped up Airtable to add to its portfolio of software companies, alongside AOL, Evernote, WeTransfer, Brightcove and Vimeo

Airtable made its name as a builder of low/no code database services, aimed particularly at non-technical staff, but is now one of many vendors facing financial difficulties in the face of the SaaS/AIpocalypse. The arrival of AI coding tools, which offer non-technical employees more flexible ways to build business applications, has hit demand for its services.

Bending Spoons bought Airtable in a deal it valued at just $1.285 billion, a far cry from the $11.7 billion Airtable was worth at its peak.

Bending Spoons has built its portfolio by buying once-successful companies like Airtable that have struggled to cope with newer, nimbler competitors or failed to adapt to emerging technologies. Bending Spoons takes these companies, cuts costs and markets them aggressively with the goal of returning them to profitability.

“Airtable is a pioneering brand reshaping how teams organize data and manage critical workflows. We’re committed to investing in Airtable for the long run, and doubling down on its core strength: bringing teams and workflows together in one flexible workspace. We plan to expand what can be done across the full spectrum of work and make Airtable even more valuable to customers at every scale,” said Luca Ferrari, Bending Spoons CEO and co-founder.

A Canadian hacker has admitted being part of a group responsible for several major cyberattacks. Connor Riley Moucka pleaded guilty to being part of a coterie of hackers that hit 165 organizations, resulting in the theft of customer records and the extortion of millions of dollars.

Industry sources have identified Moucka as one of the main players in attacks on data hosted by cloud data warehouse Snowflake. Companies affected by the hacks include the likes of AT&T, Ticketmaster and the Neiman Marcus Group.

He worked with two other hackers: John Edward Binns and Cameron John Wagenius. Binns was not in US custody as of April 2026, while Wagenius, going by the name of Kiberphant0m, was arrested in January 2025 and pleaded guilty in July that year

Moucka and other members of the group used stolen login credentials to compromise data belonging to at least 165 customers of a US-based software-as-a-service company. This unauthorized access was used to steal billions of sensitive customer records and download terabytes of information,

“Connor Moucka hacked over 150 companies and organizations, obtained extremely sensitive information, and extorted the victims for millions of dollars. Today’s guilty plea serves as a reminder to all cybercriminals, regardless of where they live, that they cannot hide behind a wall of anonymity. You will be found and brought to justice,” said assistant attorney general A. Tysen Duva of the Justice Department’s Criminal Division

The trial is the result of a coordinated worldwide action against the Snowflake group. The investigation was led by the FBI but benefited from contributions from the Royal Canadian Mounted Police, the Australian Federal Police, Spain’s Guardia Civil, the Security Service of Ukraine and the Turkish National Police.

This article first appeared on CSO.

After two decades of cloud architecture consulting, I see an unchanging pattern in enterprise deployments. Organizations approach me with unexpectedly high cloud bills, operational chaos, and architectures that look good on paper but cause headaches in production. The common thread is almost always the same. Fundamental concepts that should be foundational to any cloud deployment are treated as optional or ignored altogether.

I’m not talking about exotic requirements, bleeding-edge technologies, or vendor-specific best practices. Basic engineering principles are somehow getting lost amid the excitement of cloud adoption. I wish I could say it’s rare, but after working with organizations across industries and geographies for years, I can confirm that missing these fundamentals is more common than most people realize. The results are predictable. Bills grow faster than business value, architectures require constant firefighting, and teams are stretched too thin to optimize anything.

The good news? You don’t have to start over, but you do have to go back to basics. Here are three concepts most cloud architects overlook that will make your architecture dramatically more valuable and efficient.

Identifying common ground

When deploying heterogeneous architecture, especially in multicloud environments, organizations must aggressively reduce silos. This means establishing common control planes for security, governance, and operations. You won’t get there by relying on whatever proprietary technology each cloud provider offers out of the box. Each provider wants you locked into their way of managing things. That is fine for simple deployments, but when you are running across multiple clouds and on-premises systems, proprietary control planes introduce redundancy, complexity, and cost.

You need a single control layer that spans your entire environment. Instead of managing 10 different security solutions from 10 different providers, you have one. Instead of separate identity management systems for each cloud, you need one that works everywhere. This eliminates the need to change security parameters in five different consoles, maintain five different skill sets for five different operational models, and reconcile five different governance frameworks. The common control plane ties everything together.

This might sound hard, but it’s not as bad as you think. (I will cover the specific patterns in a future article.) The real issue is that most architects have never been trained to think this way. They were taught to select the best services from each provider rather than abstract away the differences. This fundamental gap costs organizations real money every single day.

Cost observability and optimization

Most architects treat cost visibility and optimization as afterthoughts, things that can be bolted on after the architecture is in place. That backward approach shows up in the results. Without cost observability and optimization baked into your architecture from day one, you cannot understand where your money is going, where waste is accumulating, or where you should make changes to align expenses with delivered value.

The more complex and heterogeneous your environment, the more critical this becomes. You need a unified cost observability layer that spans public and private clouds and your own infrastructure. This is about building a layer that aggregates cost data from everywhere, provides a single source of truth for spending, and delivers the insights needed to actively optimize. Without this, you are flying blind, making decisions based on incomplete data and discovering problems only after the invoice arrives.

Too many organizations fail to gain control of their cloud spending because their billing data is scattered across multiple consoles, with no way to correlate usage across providers. They cannot see which teams, projects, or services are driving costs. They miss opportunities to right-size, consolidate, or eliminate waste. You cannot improve what you cannot measure. Without a common cost observability and optimization layer built into your architecture, you will never achieve the efficiency the cloud was supposed to deliver.

Consider the human element

Here is an uncomfortable truth most architects do not want to discuss: The more complex your architecture is, the broader the range of skills you will need to keep it running. Complexity requires expertise, and expertise requires hiring, training, and retention. If your architecture demands 15 different skill sets to operate, you’d better have a plan for finding and retaining the people with those skills.

I have seen beautifully designed architectures fail because the organization could not meet hiring requirements. They compromised by hiring underqualified individuals, which led to operational failures, security gaps, and mounting technical debt. The architecture itself was sound. The human infrastructure around it was not. This is a solvable problem. It starts with acknowledging that you are not designing for yourself. You are designing for the team that will inherit this system after you have moved on to your next assignment or promotion.

The solution isn’t just simplifying architecture, though that should be a goal. The key is to consider human factors in your design. What skills are required? How can you find and train people? What cultural changes are necessary for effective operation? These questions are essential; ignoring them risks failure.

The simple bottom line

I understand why most cloud architects miss these basic principles. No single course or book brings all of this together in one place. Cloud architecture has become a collection of best practices, vendor recommendations, and conference talking points, rather than a disciplined engineering discipline focused on business value.

As a result, architectures end up optimized in the wrong places, if they are optimized at all. They are expensive to run, difficult to secure, and nearly impossible to operate at scale without constant intervention. The cloud promises efficiency, yet we are not delivering it because we have lost sight of the fundamentals.

It’s time to go back to basics. Commonality, human factors, and cost observability and optimization are the three things that separate architectures that create value from those that create cost. Incorporate these concepts into your architecture and you’ll get ahead of most production systems in use today.

Wispr, the startup behind dictation tool Wispr Flow, has created an AI note-taking assistant that records meetings and generates conversation summaries for users.

The Wispr Flow Notetaker tool “captures your meetings so you can stop splitting your attention between listening and writing things down,” said Sahaj Garja, Wispr CTO and co-founder.

Notetaker starts recording with one click, and doesn’t require a bot to attend a video or voice call. It can also be used to capture in-person conversations.

The software has three key functions. Before a call, Notetaker displays a meeting brief with information such as meeting purpose and background of participants.

Once the meeting starts, a live transcript displays the dialogue text and labels speakers. A “what did I miss?” button provides a summary of talking points from the previous few minutes.

Finally, post-meeting, Notetaker generates a more detailed summary organized by topic that includes information such as key dates, decisions, and next steps. Users can search across notes from previous meetings in the Notetaker app. “Over time your meeting history stops being a folder of documents you have to go find and becomes something you can ask questions of,” said Garja.

Notetaker integrates with AI assistants such as Anthropic’s Claude and OpenAI’s ChatGPT via model context protocol. This allows users to connect outputs such as transcripts and summaries “into how you already work, instead of sitting in a separate app,” said Garja.

With Notetaker, Wispr competes in an increasingly busy market for AI note-taking apps that includes Fireflies, Granola and Otter.

Wispr claims Notetaker can produce more accurate transcripts than existing tools, partly because of the additional context it uses during transcription. It uses the same personal dictionary from Wispr Flow that includes acronyms, products, and preferred spellings, and can also draw on other sources such as calendar information to understand the purpose of a meeting and help ensure speakers are labelled correctly.

Before generating the final summary, Notetaker also re-reads the live meeting transcript and combines it with additional context to create a more accurate final output, Garja said.

Notetaker is the first new product launched by Wispr, which was founded in 2021 and has since raised $81 million in funding.

“We didn’t set out to build a dictation app,” said Garja. “The mission has always been to reshape how people interact with their devices, and dictation was the fastest way in.”

“Notetaker is the second product on that path. Dictation took the keyboard out of writing. Notetaker takes it out of meetings, so nobody has to spend the call typing up what everyone just said.”

User consent when recording calls

As AI note-taking tools have become more prevalent in the workplace, privacy concerns have arisen, including the need for all-party consent when recording a call in some jurisdictions, and whether meeting audio is used to train AI models. Two software vendors, Otter and Granola, currently face separate lawsuits in California that allege privacy law violations related to their products.

Wispr Flow Notetaker captures audio locally on a user’s device rather than joining the call as a visible bot. That means there’s no notification to signal that a conversation is being transcribed, which places responsibility on users to disclose the recording to others on the call in accordance with local laws, said Garja.

“Users should always let the other person know before you start recording or transcribing a conversation, whether it’s a video call, an in-person meeting, or a phone call,” he said, adding that Wispr intends to build additional features for automated consent messaging “in the coming weeks.”

Wispr doesn’t train its AI models on customer data without consent, though free and standard tier customers must choose to opt-out, according to Wispr’s privacy terms. Nor does it create “voiceprints or biometric profiles” of users or anyone else on a call using audio recording data, the company says.

When Notetaker is active, conversation audio is captured on a user’s device and processed on cloud servers to enable transcription. The recorded audio file is encrypted and stored temporarily on the user’s device or cloud storage, Wispr said. After a limited period, the audio is automatically deleted.

Notetaker is available with the Wispr Flow macOS app to free and paid subscribers, with support for Windows “coming soon.”

AI-generated vulnerability patches still heavily depend on human review, particularly the ones involving security-sensitive code, according to a research.

Researchers from 1Password have disclosed an internal evaluation that found AI-generated fixes frequently overlook broader concerns such as architectural intent, business requirements, security implications, and long-term maintainability, despite being syntactically correct.

“We studied what happens when Large Language Models (LLMs) generate vulnerability patches for recently disclosed, complex vulnerabilities,” said 1Password researcher Keith Hoodlet in a blog post. “Our data shows that LLMs produce Fix-Like Artifacts with Embedded Defects (FLAWED) 53.9% of the time when complex patches are required.”

The evaluation tested the AI-generated fixes across six recently disclosed CVEs, including CVE-2026-31431 (“Copy Fail”), CVE-2026-34197 (ActiveMQ RCE), CVE-2026-8512, CVE-2026-45185 (EXIM RCE), CVE-2026-22738 (SpringAI SpEL RCE), and the Gemini CLI RCE (GHSA-wpqr-6v78-jr5g).

1Password reportedly evaluated 6080 patches generated using ChatGPT-5.5 and Claude Opus 4.8, two frontier AI coding models, and found that only a little over a quarter of the fixes fully remediated the flaw without altering application behavior.

“Patches that successfully resolved the vulnerability, but altered the application’s behavior in the process, occurred 20.1% of the time,” Hoodlet added.

Fixing is not the same as securing

Instead of simply checking whether the fixed code compiled or passed automated tests, 1Password said it reviewed every generated fix for complete elimination of the vulnerability, preservation of application behavior, and avoidance of new security risks.

While only 26% of the patches successfully fixed the vulnerability without introducing application changes, 49.3% failed to remove at least one exploitable attack path, 2.3% fixed the original vulnerability but introduced a new one, and 2.2% both failed to remediate the issue and created an additional security weakness.

The researchers also found that passing pre-defined tests can create deeper problems. More than one-third of the patches that initially appeared successful were classified as “fragile” because they simply blocked the proof-of-concept (POC) exploit used during testing instead of addressing the underlying root cause.

Hoodlet explained this with the example of the SpringAI CVE patches. Both GPT and Claude models were found generating patches that targeted specific characters from the input string used in the POC presented to them, leaving the root cause untouched.

“If the guarded code were to become reachable again by using alternative inputs, it would lead to the old vulnerability resurfacing in the software,” he noted.

Human review remains the last security control

1Password argues that these shortcomings stem from the contextual reasoning required to produce production-ready security fixes.

Anthropic was reached out to and reportedly recommended keeping humans in the loop. “Patch generation has outpaced patch verification, and the fix is to make verification execution-grounded rather than inspection-based, while keeping domain experts as the final reviewers at current model capabilities,” it was quoted as saying.

1Password also challenged the notion that AI-generated patches are effectively “free.” While the average patch-and-validation cycle cost approximately $2.11 using ChatGPT-5.5 and $2.81 using Claude Opus 4.8, Hoodlet argued that the real expense lies in validating whether those patches are secure enough for production.

The financial impact of a data breach is substantial for any modern business, regardless of industry or size. IBM’s latest Cost of a Data Breach report discovered that, from March 2025 to February 2026, the average cost of a data breach rose to $6 million, up 35% from $4.44 million a year earlier.

The 2026 report, conducted by Ponemon Institute and sponsored by IBM, is based on an analysis of data breaches experienced by 600 organizations globally.

According to the report, one in four malicious breaches were AI-enabled. Deepfake impersonation and AI-enabled malware made up the majority of these AI-assisted attacks.

The study found that AI and automation in security operations cut breach costs by an average of almost $2 million dollars. Despite that impact, one in four organizations have yet to adopt these tools in their security operations, the survey found.

In a follow-up study, more than half the organizations reported using agents for threat detection and containment but only 18% apply agents to vulnerability management. Three in four of the enterprises polled say that frontier AI threats are prompting them to rethink how agents are deployed across their security operations.

“AI is making attacks faster and cheaper, while breaches keep getting more expensive. When organizations have an extended gap between discovery and remediation, that imbalance shows up directly in breach costs,” says Suja Viswesan, VP of IBM Security Software.

AI models under attack

One in five organizations reported a breach targeting AI models or applications. The most common causes were weaknesses in surrounding systems: compromised APIs, applications, or plug-ins (27%) and cloud misconfigurations affecting AI workloads (27%).

The vast majority of organizations suffering AI-related breaches lacked proper access controls, yet only 40% deployed access controls on their AI models and data.

Improving access controls on AI models is the most obvious security gap to close, according to Kayne McGladrey, a senior member of IEEE, CISSP-certified cybersecurity advisor, and former CISO of compliance automation vendor Hyperproof.

“Treat your models and their APIs like crown jewels,” says McGladrey. “If you wouldn’t expose your database to the public internet without identity and access controls, why would you do that for your AI model?”

Udaya Bhaskar Vemuri, senior application security analyst and DevSecOps professional, adds that organizations should also be “reviewing integrations and plug-ins, monitoring unusual activity, protecting sensitive data, and making sure every AI system has a clearly defined owner who is responsible for its security and oversight.”

Prompt criticality

Beyond deepfakes and AI malware, AI-driven phishing and direct attacks on AI models, such as prompt injection, are emerging as costly enterprise blind spots.

“The threat isn’t just external; unapproved employee use of AI applications introduces unmanaged vulnerabilities into corporate environments,” says Dray Agha, senior manager of security operations at managed detection and response firm Huntress.

CISOs must shift to proactive governance by embedding security into development workflows, managing exposures aggressively, and applying strict access controls to AI workloads, Agha advises.

Peter Garraghan, CSO and founder at AI security testing firm Mindgard, adds that blindly trusting in the effectiveness of AI security guardrails is fraught with risk.

“Research has demonstrated that existing guardrails currently have various blind spots, and that a defense in depth approach is required,” says Garraghan. “Attackers are constantly adapting, so organizations need to continuously test AI models and applications against realistic adversarial attacks to identify where protections fail.”

Garraghan adds: “By validating guardrails before and throughout deployment, CISOs can ensure AI systems are resilient enough to protect sensitive data, and user privacy as threats evolve.”

Attackers are compromising APIs, plug-ins, and cloud misconfigurations around models rather than defeating them, according to Ariel Parnes, co-founder and COO of cloud security vendor Mitiga.

“These attacks land in the telemetry of the cloud and identity environments, not in the model itself, so the defense is behavioral detection across everything the AI touches,” Parnes advises.

Upping the ante

The abuse of AI tools by attackers doesn’t just mean enterprises are subject to more sophisticated attacks. It also means that these attacks unfold more quickly.

“Organizations need to respond with the same level of automation, but with strong guardrails,” says John-Paul Cunningham, CISO at identity security vendor Silverfort. “AI can improve the speed of cyber defense, but only if organizations build governance and accountability into those systems from the start.”

Regional costs

Average breach costs in the US reached a record $11.5 million, an 11% increase over last year and nearly double the global average.

This rise was driven in part by steeper regulatory penalties and higher business costs, according to the IBM-sponsored study.

The Middle East, which considered Saudi Arabia and the United Arab Emirates for the report, was No. 2 of the 16 countries and regions surveyed, at $8 million.

Canada ($5.2 million) and the UK ($4.17 million) remain in the top 10 hardest hit, with ASEAN or Association of Southeast Asian Nations ($4.12 million), Australia ($2.96 million), and India ($2.79 million) among the top 15.

Phishing topped initial attack vectors and led to the costliest breaches. Social engineering, such as impersonating help desk staff, was used in 13% of attacks while voice and SMS phishing featured in 17% of attacks.

Breaches by industry

Healthcare remains the industry hit with the highest average costs per breach at $6.64 million despite a drop from $7.42 million last year.

Attackers continue to value and target the industry’s patient personal identification information (PII), which can be used for identity theft, insurance fraud, and other financial crimes.

The mean time organizations took to identify and contain a breach rose to 247 days, a slight 2.5% year-on-year increase that reversed a five-year decline. “New threats from AI-driven attacks are challenging even the quickest response times,” the IBM-sponsored study notes.

Average breach cost by industry

Breach cost variables

While industry averages provide benchmarks, calculating the true, final cost of a specific data breach is notoriously difficult and relies heavily on forecasting.

“Immediate technical costs are quantifiable, but devastating long-term impacts like reputational damage, lost business, and regulatory fines are intangibles, making total breach cost figures informed estimates rather than exact science,” says Huntress’ Agha.

Several experts quizzed by CSO named the cybersecurity skills gap, supply chain vulnerabilities, and the escalating threat landscape as the three main factors in making breaches more expensive and harder to manage.

AJ Thompson, chief commercial officer at IT consultancy Northdoor, who sits on IBM’s Worldwide Security Advisory Council advising on data access and security, says the “bigger cost driver is still ‘how fast you spot a breach’ rather than the sophistication of an attack.”

“A shortage of experienced security staff and patchy visibility into supply chain and third-party risk both stretch out that detection window, and every extra week unnoticed adds to the bill,” Thompson adds.

Reputational damage remains a key cost of being breached

In many ways immeasurable, reputational damage remains among the most significant costs in the wake of a breach. “Ultimately, customer trust is very easy to break, and very difficult to build,” Allie Mellen, senior analyst at Forrester, tells CSO.

Bob Dutile, chief commercial officer at UST, agrees: “The cost of a data breach is typically realized in relative competitive change in the marketplace. Companies find that their brand does not command the same price premium, customer conversion costs are higher, and market share is lost. For a public company, the near-term assessment of the cost impact is reflected in stock price movement.”

According to Dutile, research shows that between $8 million and $10 million is a good planning number in the US for a midsize business facing a modest breach of under 250,000 records. About a third of that cost will be loss of business due to reputation damage.

How a company responds to and communicates a breach can have a large bearing on that reputational impact, Forrester’s Mellen notes. “Understanding how to maintain trust with your consumers and customers is really critical here,” she adds. “There are ways to do this, especially around building transparency and using empathy, which can make a huge difference in how your customers perceive you after a breach. If you try to sweep it under the rug or hide it, then that will truly affect their trust in you far more than the breach alone.”

Severe business downtime can cost millions

Business downtime can also be significantly costly for a breached organization, depending on the level and extent of the downtime and how technology-dependent the firm is.

Nearly all the organizations studied suffered operational disruption, taking an average of 100 days to recover from a security incident.

Jason Hicks, field CISO at Coalfire, tells CSO: “Often a breach is not going to take a company completely offline, but it can happen. The more critical systems that are taken down, the more significant the cost.”

Manufacturing tends to have the best metrics around this, as it’s relatively simple to measure the cost per minute if an assembly line is down, Hicks says. “This can translate into millions of dollars a day for a large manufacturing company. This can be more nebulous for other industry verticals, but there are models to get a reasonable feel that can be applied to each vertical.”

Regulation and litigation add to data breach costs

Increasingly strict data protection and privacy laws along with litigation are seeing a growing number of companies issued large fines, paying hefty settlements, and stumping up for legal fees following data breaches and non-compliance.

“Regulated industries suffer not only the immediate cost of responding to, containing, and remediating vulnerabilities but also the long-term effects of additional penalties from their regulatory bodies and legal settlements,” Nick says. Highly regulated industries, such as healthcare and financial services, typically run one and two in order of cost per breach because they will pay more non-compliance fines than others, he adds.

“Investigation and adjudication often take years for the victim organization to reach a monetary settlement with affected parties.” Legal costs are one of the largest expenditures organizations face in data breaches, Nick states. “Organizations rarely have the legal and privacy expertise in-house. To ensure compliance, they must hire outside counsel to lead their reporting.”

The role of cyber insurance

Cyber insurance is one way that companies mitigate the cost risks of breaches. Sharp increases in cyber insurance premiums have been stabilizing of late, but even organizations covered by insurance can expect to dole out extra cash to make good after a breach. One definite cost hit will be a hike in their premiums, Guidehouse’s Nick says.

“Some organizations have reported post-breach increases in premiums of approximately 200%,” he adds.

Insurers are also implementing more coverage limitations, meaning that even with a policy in place, businesses could find themselves financially responsible for certain breach-related costs.

In fact, Forrester’s Mellen says any notion that policies will allow organizations to fully recover financially from a cyberattack is folly. “In reality, it’s not going to cover all of the costs associated with any type of cyberattack, and we see some insurance firms not even covering ransomware at this point as part of their payouts,” she adds.

Another factor to consider is that cyber insurance providers typically have a list of approved service providers such as lawyers and forensics firms, Hicks says.

“If your preferred provider is not on their list, you may have to work with them to get them included, or potentially have to change providers. This can be costly, as firms are often leveraging their existing service providers to secure the maximum discounts based on the volume of work done with the partners,” Hicks says.

Ransomware extortion on the rise

Reported ransomware incidents rose in the last 12 months compared to the year prior (39% vs. 34%) as attackers have abused AI technologies to automate and scale their attacks.

While disrupting operations through encrypting remains a key tactic (23%), attackers are shifting to higher-impact pressure methods, such as threatening to leak stolen data (a common feature of so-called double extortion attacks).

Insufficient security staffing leads to higher breach costs

According to IBM’s latest report, the security skills shortage is one of the biggest data breach cost amplifiers, with the average additional cost of data breach due to cyber skills shortage pegged at $180,000.

If insufficient security staff equates to greater data breach costs, organizations should heed Mellen’s warning about the impact a poorly handled data breach can have on employees.

“If they don’t feel like the organization is able to protect them or customers in the event of a breach, or that they blame their employees for a breach, then they’re likely going to start looking for jobs elsewhere because it creates a bit of a hostile environment for them,” she says. “It is very important for organizations to recognize that they need to accept responsibility and protect both their employees and their customers.”

Taking a DevSecOps approach to software development was the No. 1 factor that reduced breach costs, according to the report, ahead of use of identity and access management. Running key lifecycle management tools rounded out the top three factors.

Security incidents involving shadow or unsanctioned use of AI tools more than doubled to 43% this year compared to 20% in 2025. Shadow AI is starting to rival supply chain breaches and security system complexity as a leading factor in exacerbating breach costs, according to the report.

Preparedness is key to managing data breach costs

No matter the specific costs involved, experts agree that preparedness is key to mitigating the financial repercussions of a breach.

“Faster incident response continues to be a clear driver for lowering the cost of a breach,” UST’s Dutile says. “The worst losses are those that go undetected for an extended time or have a slow or ineffective response.”

To that end, more than half of organizations surveyed say they plan to invest in AI security and governance tools post-breach, an 88% increase from last year and a reaction to concerns over frontier AI model threats.

Modern cybersecurity requires a post-breach mindset which understands that, eventually, a successful data breach is going to occur, Forrester’s Mellen adds.

“Operating under those conditions, you need to figure out how you’re going to handle that and build your resiliency to respond better and faster. This isn’t just about the security function either, and it needs to be spread across an organization, considering what marketing is going to do, what sales is going to do, etc. — how, as a business, you can demonstrate you value your customers and that you want to make it right as quickly and effectively as possible,” she says.

For years, applicant tracking systems and recruiting platforms were treated as HR technology: Important for workflow, efficiency, compliance and candidate experience, but rarely viewed as core security infrastructure. That assumption no longer holds. Once AI begins reading resumes, scoring candidates, conducting interviews, ranking applicants and influencing who moves forward, the hiring platform stops being a passive system of record. It becomes a decision system.

And any system that accepts public input, processes sensitive data and influences business decisions belongs inside the security conversation.

I learned this during an AI hiring platform rollout that never made it to production. The vendor was established, the product had a strong market reputation and the AI feature looked attractive: Upload a resume, compare it to a job description and return a neat percentage match. For recruiters, it promised speed. For executives, it promised modernization.

Before moving real candidate data into the system, I tested it with synthetic resumes. One weak resume came back with a surprisingly strong match. The reason was not hidden in the candidate’s experience. It was hidden in the text. The resume contained language instructing the AI to treat the candidate as an excellent fit, and the system appeared to follow that instruction instead of evaluating the resume on merit.

That changed the question from “Does the tool improve productivity?” to “Can the person being evaluated influence the evaluation itself?”

That is a security question.

The trust boundary has moved

CIOs do not need to become recruiting experts. They only need to look at the mechanics.

An anonymous user submits content into an enterprise system. That content is processed by software. The software then produces an output that can influence a business decision. In every other environment, security teams know what to call that: untrusted input crossing a trust boundary.

The difference is that in hiring, the input looks harmless. It is a resume, a cover letter, a chatbot reply or a spoken answer in an AI-led interview. But once AI reads that content and treats it as instruction, the harmless-looking input becomes part of the system’s control surface.

That is why prompt injection matters in hiring. It is not just an AI oddity or a model behavior issue. It is the same category of failure enterprises have spent decades trying to prevent: User-controlled input changing what the system does. OWASP lists prompt injection as the first risk in its Top 10 for LLM applications, describing it as a case where user prompts alter a model’s behavior or output in unintended ways.

In hiring, the implication is direct: A candidate may be able to manipulate the score, ranking or interview assessment that determines whether a human ever sees them.

The business impact is not theoretical

The obvious risk is that an unqualified candidate moves forward. But the impact is broader.

First, decision quality degrades. Hiring teams adopt AI scoring because they believe it improves signal. If the score can be manipulated, the business is not gaining signal; it is gaining false confidence. Recruiters may spend time on candidates who gamed the system while stronger candidates are buried lower in the queue. A tool bought to reduce friction can quietly create more of it.

Second, cost increases under the appearance of efficiency. Every false positive consumes recruiter time, hiring-manager attention, interview slots and opportunity cost. A small weakness in screening integrity can become a measurable operational drag across open roles.

Third, trust suffers. Candidates already question whether AI hiring tools are fair, explainable or accurate. If it becomes clear that a screening system can be manipulated by hidden instructions or verbal prompting, the issue is no longer just security. It becomes reputational. Strong candidates may lose confidence in the process, and employers may have to defend decisions made by systems they did not fully understand.

Fourth, sensitive data exposure becomes harder to contain. Recruiting systems hold names, addresses, work histories, education histories, compensation details, work authorization information and sometimes accommodation or demographic data. NIST guidance on personally identifiable information includes employment information as linkable personal data that must be protected from inappropriate access, use and disclosure. Yet hiring platforms often receive less security scrutiny than systems holding customer or financial data.

That mismatch is dangerous: High-value data, public-facing workflows and increasing automation.

The 2025 McHire incident should have made this impossible to ignore. Researchers reported that weaknesses in McDonald’s AI hiring platform, including default credentials and an access-control flaw, exposed applicant data at large scale before the issue was patched. The lesson for CIOs is not merely that a weak password was used. The lesson is that AI hiring systems can ship with basic, preventable security failures while still being treated as HR tools rather than enterprise risk surfaces.

Vendor reputation does not transfer to every AI feature

One reason this risk slips through is that buyers often trust the platform brand. Mature vendors may have strong security programs, enterprise customers, compliance documentation and procurement-friendly answers.

But AI features can change the architecture of risk.

A platform that was safe as a workflow tool may behave very differently once it adds resume scoring, interview grading, chatbot screening or automated ranking. The new feature may introduce new inputs, new model behavior, new data flows, new third-party dependencies and new decision points. In practical terms, the attack surface has changed.

CIOs should not allow AI features to inherit trust automatically from the legacy platform around them. When a vendor adds AI, the enterprise should reassess the feature as if it were a new product. That does not mean slowing innovation for bureaucracy. It means AI-enabled decision-making carries different failure modes from ordinary workflow automation.

The ownership gap is the real vulnerability

The biggest risk may not be the model. It may be the ownership gap.

Talent acquisition may buy the tool. HR operations may configure it. The vendor may guide implementation. Procurement and legal may approve the contract. But who owns the security of the candidate-facing AI layer?

In many organizations, the honest answer is unclear.

That ambiguity is where risk grows. Recruiting technology sits at the intersection of public input, sensitive data, third-party software, automated decision support and brand trust. That is exactly the kind of environment that needs named security ownership, asset inventory, vendor review, access-control testing, logging and incident-response planning.

If the hiring stack is not in the security inventory, the organization is already making an assumption it may later regret.

What CIOs should require now

The fix is not exotic. It is applying existing security discipline to a surface that has been underestimated.

Treat every candidate submission as untrusted input. Resumes, cover letters, chatbot responses, interview transcripts and spoken answers should be handled as attacker-controllable content. If AI processes it, the system must separate content from instruction.

Reassess vendors when AI features are introduced. A prior security review should not be treated as permanent approval for new AI capabilities. Ask what changed in the architecture, what data the model sees, what actions it can influence and how manipulation attempts are detected.

Ask AI-specific questions before signing. Can candidate-provided content alter scoring? Are hidden instructions filtered or ignored? Is there human review before AI output influences a decision? Can the vendor produce testing evidence for prompt injection, access control and data exposure risks?

Assign ownership. HR can own the process, but security must own the risk model. AI hiring systems should be included in third-party risk management, application security reviews, access governance, monitoring and incident response planning.

Measure business impact, not just AI adoption. The goal is not to say the recruiting function uses AI. The goal is to improve hiring speed, quality, fairness and cost without creating new risk. If the system cannot protect decision integrity, the business case is weaker than it appears.

The hiring platform is now part of the enterprise attack surface

AI has turned the careers page into more than a front door for applicants. It is now a public input channel feeding systems that store sensitive data and influence workforce decisions.

That makes it a CIO concern.

The next failure in AI hiring may not look like a traditional breach at first. It may look like bad rankings, manipulated scores, unexplainable decisions, wasted recruiter time or a candidate process no one trusts. But underneath those symptoms is a familiar security problem: A system trusted input it should have treated as hostile.

Enterprises have hardened payment systems, customer portals, APIs and employee applications around that lesson. Hiring deserves the same treatment.

AI hiring is not just an HR transformation. It is a security boundary. And it is time CIOs treated it like one.

AI’s impact has been felt across nearly every industry, and its rise has already started to alter several roles in tech, including that of the business analyst. While the rise of agentic AI may have some questioning whether AI will replace business analyst jobs entirely, as we’ve seen with most roles impacted by AI, it’s more likely that AI will augment the role and fundamentally change how BA’s conduct daily business.

“As AI takes on more routine tasks, the human side of the role is becoming even more valuable. It’s becoming more of a hybrid role, where employers are often looking for candidates who can combine technical fluency with strong communication and problem-solving skills, along with sound business judgment,” says Megan Slabinski, district president of technology talent solutions at Robert Half.

AI can save business analysts time in the long run, automating many of the tasks that are time consuming and repetitive around data processing, note taking, and documentation. While automation will impact the daily tasks of the role, business analysts will still be necessary for properly interpreting outputs, collaborating across teams, and maintaining compliance and AI workflows.

AI-driven analysis and automated workflows

With AI-driven analysis, BA’s can use machine learning models for pattern detection, determining risk, and for forecasting demand, while natural language processing (NLP) can be used for text-heavy inputs. AI tools can also assist analysts with decision-making by transcribing meetings and automatically identifying any necessary business requirements, constraints, risks, or dependencies that will impact the project.

As a result, the role is undergoing a shift toward spending less time on monotonous, routine tasks, and instead “spending more time connecting the dots and providing strategic context earlier in the process,” says Slabinksi.

“We’re seeing that business analysts today aren’t spending as much time as they were a few years ago on some manual processes. AI is speeding up tasks like documenting requirements, summarizing stakeholder meetings, generating first drafts of user stories, and even helping create SQL queries or reports,” she adds.

AI can also assist business analysts with interviews and workshops for the discovery phase of a project and autonomously identify patterns in the data that might be overlooked or missed by the human eye. These tools can also enable BAs to create living models that can be adjusted and altered with feedback, as opposed to traditional static documents, and allow for an automated review process for data validation. In terms of maintenance and change management, AI can help with predictive recommendations to get ahead of risks, compliance, and future process updates.

That said, an increased reliance on AI tools while require business analysts to validate AI outputs and assure AI-generated content is accurate, relevant, and ultimately aligned with the overall business strategy. Still responsible for explaining the reasons behind business decisions, business analysts will also need to identifying bias and fairness concerns associated with AI use, and ensure decisions aren’t over-automated.

Ultimately, BA’s will see their responsibilities shift to focusing more on data interpretation, governance, and strategy, and identifying the most practical use cases for enterprise AI adoption.

New skills to focus on

Traditionally, business analysts are responsible for gathering the data as well as processing it for analysis. This comes with a lot of drudgery that can be eased by implementing AI tools into the workflow. Tasks such as routine documentation, formatting, and data crunching can be automated, while analysts provide the human context around that data, as well as a critical eye to the final output.

“Business analysts are often in the mix to make sure that data is accurate and that the requirements are in line with expected outcomes. They can also help ensure AI projects include the appropriate level of human oversight, comply with internal policies and industry regulations, and use data responsibly. While they aren’t solely responsible for AI governance, they often play an important role in raising questions about data sources, bias, whether the outputs make sense, and potential business risks early in a project,” says Slabinski.

BAs will need to develop AI literacy skills to better understand how models are trained and designed as well as data reasoning skills to interpret and validate AI outputs. Prompt-framing skills will also become valuable as analysts will need to know how to properly structure inputs for quality outputs. There will also be a growing emphasis on ethical analysis to identify compliance, bias, and overall fairness of algorithms, and qualified candidates will require strong change management skills to help oversee the adoption of AI-driven workflows.

“The skills becoming more important are the ones that help BAs evaluate AI-generated information and translate it into business recommendations. AI literacy is becoming a baseline expectation, and that includes knowing things like how to query the data and support requirements gathering. Critical thinking, communication, and business acumen are all part of that skill set because employers still need people who can explain what the findings mean and why they matter,” says Slabinski.

It’s no secret that the CIO role is changing in Canadian enterprises. Driving operational performance and increasing efficiency are, of course, still a big part of the job. But CIOs are now expected to do more than cut costs and keep the lights on. Increasingly, boards of directors expect the CIO to play a key role in creating value and enabling their organizations to outperform their rivals. Recent data backs this up. The overwhelming majority (91%) of Canadian technology leaders believe advanced technology will be the primary driver of competitive advantage over the next three years, according to KPMG’s “The 8 execution imperatives for Canadian tech leaders,” a white paper based on the firm’s 2026 Global Tech Report.

The race to capture value from emerging technologies has intensified, leaving little room for organizations that remain on the sidelines. Yet in Canada, just 27% of organizations consider themselves innovators or early adopters, while 72% are fast or slow followers. Nearly all (85%) believe they’ll need to take more risks with emerging technologies just to remain relevant.

The traditional, operational-first mindset among CIOs has become a liability. CIOs are expected to be strategic players, but meeting that expectation requires taking thoughtful, well-considered action across key imperatives.

AI success depends on data

AI is not the only advanced technology that organizations are working to deploy, but it’s certainly garnering the most attention from C-suite executives, boards of directors, and investors. To enable AI at scale, the data foundations enterprises have built over the past decade will be necessary, but they are not sufficient on their own. CIOs must make modernizing the state of enterprise data a top priority.

In most large organizations, data often remains locked inside legacy systems where the system of record is also the system of engagement, and that significantly limits accessibility for AI workloads. Data should be treated as the strategic asset that it has become. The quality, timeliness, and governance of that data vary widely, and reconciling those inconsistencies is one of the most persistent barriers to enterprise-level deployment.

Scaling pilots into enterprise programs also requires closing the gap between AI-native talent, who have the skills to move quickly, and those with deep institutional knowledge, who understand how their organizations work and what they need to achieve. These two groups must work hand in hand. Otherwise, organizations may accelerate toward the wrong goals, which won’t move the business forward.

“The barriers to scaling AI aren’t just technical,” says Sanjay Pathak, partner and national leader, technology strategy and digital transformation services, KPMG Canada. “CIOs need to truly and deeply understand the value chain of what their organizations do. Those who get there will have the imagination, the courage, and the foresight to use AI to transform their organizations.”

Communicating ROI requires the right framing

Beyond scaling, simply communicating the value of AI also poses a significant challenge. Just over half (53%) of Canadian organizations surveyed say they struggle to demonstrate or communicate AI value to stakeholders. Part of the problem is that CIOs are making the wrong argument in the wrong room because they’re framing ROI as a technology metric rather than a business outcome.

“Any CIO who doesn’t truly understand what their business does is missing a beat around how innovation is going to help the organization achieve ROI,” says Pathak. “Understanding how to deploy AI inside your value chain will give you a head start and a competitive advantage in unlocking real business benefits.”

A formal performance measurement framework that tracks customer experience, revenue growth, and employee adoption alongside cost metrics gives CIOs a far more accurate picture of long-term value. Linking funding decisions to those strategic outcomes makes sustained investment easier to justify.

There is also a compliance dimension that often goes unacknowledged in these conversations. CIOs who bring business, technology, and compliance leaders together to design innovative processes that are “compliant by design” from the start are protecting future value as much as they are delivering value today.

“You need to assemble that multi-dimensional cohort of business, technology, risk, and compliance leaders at the same table, envisioning compliance by design,” says Pathak. “The winners in this space are going to be the ones who really think about business ambition holistically and focus on efficient delivery, operations, and compliance.”

Building disciplined innovation governance

An organization’s approach to governance makes an enormous difference in how quickly and confidently it can deploy and take advantage of advanced technologies. As noted above, almost three-quarters (72%) identify as fast or slow followers, and 85% say they need to move more aggressively to embrace new technologies. Canadian organizations aren’t lacking ambition. What they lack are the conditions required to innovate with confidence: clear ownership, defined risk thresholds, and shared accountability between technology, risk, and business teams.

“You can be an innovator, but if your innovation is not directly connected to strategic business ambition and safety guardrails such as risk management, governance, and compliance, you’re creating labware,” says Pathak. “Being an early adopter means you’re comfortable with the technology. To make it truly viable, you must embrace all dimensions of enterprise value.”

Strong governance does not slow innovation down but instead provides a structure that builds confidence and resilience at every level of the organization, from the board to project teams. A tiered governance approach that takes risk into account allows organizations to advance low-risk, incremental improvements and high-reward initiatives in parallel.

Expanding partnerships to accelerate innovation

Innovation isn’t a single-player game, and Canadian organizations know it. Ninety-seven percent of respondents say they plan to expand their external ecosystems. To date, a significant portion of those relationships have been transactional and focused on a specific capability or problem. But savvier organizations are moving toward multi-party innovation, where partners pool capabilities to share both risk and reward. This model requires a different kind of commitment because organizations are betting on a partner’s long-term viability, not just their current capability. Together, they must build the integration and governance infrastructure that makes these ecosystems work for all participants.

“Moving to multi-party innovation ecosystems is an investment in integration and data,” says Pathak. “If you’re going to look at best of breed and stitch those together, what must be true for that to work is the ability for those different ecosystems to integrate and interoperate. And that creates a much stronger need for safety and governance.”

Cybersecurity is another dimension that grows more important with every new partner added to the ecosystem. Security should be proactively built in, not imposed after a breach has already occurred.

“The more ecosystem-based partnerships you have, the more opportunity you create along with the threat you have to deal with,” says Pathak. “You expand the attack surface, and you become more of a target, so governance and cybersecurity must be designed in from the start, not bolted on later.”

Canadian government incentives, including Scientific Research and Experimental Development (SR&ED) tax credits and AI-focused clusters, offer a way to share some of the cost and risk, particularly during periods of economic uncertainty.

By leveraging these funding frameworks alongside robust ecosystem governance, forward-thinking organizations can safely scale their networks to turn shared risks into sustainable competitive advantages.

In closing

For organizations navigating this environment, KPMG Canada emphasizes that the most consequential decisions ahead are not purely, or even mostly, technical. They are about how CIOs choose to lead, partner, measure, and govern in a period that rewards both ambition and discipline in equal measure.

The data points are clear. CIOs who lead with both strategic ambition and disciplined execution will elevate their organizations above their competitors. By paying attention to the quality of their data, aligning technical priorities with critical business goals, and instituting strong governance and cybersecurity, they will set a higher standard for what Canadian competitiveness looks like in the years ahead.

To learn more, read the full whitepaper: The Top 8 Execution Imperatives for Canadian Tech Leaders.

Salesforce customers more than doubled their agentic workforces year on year, according to the company’s second annual Agentic Enterprise Index, which looks at trends in AI agent development and deployment over the past five quarters.

It compiled data from customers who had activated agents in production every month of the analysis period to determine how their use of the technology has evolved between February 2025 and April 2026, as well as incorporating data from May 2026 Salesforce research studies.

It found that businesses grew their agentic workforces from an average of five agents in February 2025 to 13 by April 2026, a 7% compound monthly growth rate (CMGR). In April 2026, it only took an average of 1.9 days to deploy an agent into production, a 53% decrease since the beginning of the report period.

Not only were agents deployed more quickly, they have been progressively taking on more work once in use; over the 15 months, the average number of actions per account had a CMGR of 31%.

“These agents are expanding beyond their initial scope to really become cross-functional,” said Caila Schwartz, Salesforce’s head of agentic commerce insights, during a media briefing.

Salesforce has attempted to measure how much work agents perform, rather than how many tokens they consume, creating its own Agentic Work Unit (AWU) metric, although analysts have criticized the measure as being unrelated to business outcomes. Nevertheless, Salesforce said that as of April, Agentforce agents had performed 734 million AWUs, a number growing at about 15% each month.

The research also showed that agents are acting across multiple cloud domains which, the company said, “underscores the practical necessity of a headless architecture. By decoupling the agent’s logic from traditional front-end user interfaces, agents can process tasks, execute actions, and trigger workflows anywhere.”

Within the company, Salesforce itself has seen explosive growth in AI agent use, said Joe Inzerillo, president of enterprise & AI technology at Salesforce, with a threefold increase in sessions between February 2025 and April 2026. He said that the AI agent in Slack, Slackbot, saves the average employee five hours per week, with 83% of the company having adopted it.

But Schwartz pointed out that different industries are approaching agentic AI in different ways, some more sophisticated than others. To measure that, Salesforce developed a Sophistication Index, a five-point scale scoring the cognitive complexity of an agent’s actions. Levels 1- 3  are assigned to tasks such as record lookups, drafting emails, or summarizing documents, while levels 4 and 5 include more complex functions such as updating database fields.

The data showed that manufacturing, financial services, and healthcare and life sciences have built more sophisticated agent networks than what it called traditional AI frontrunners such as technology and retail.

However, Inzerillo said, the most common use case industry wide, and the best place to start, is the service use case, which provides “far and away the best ROI to start with.”

He also noted that, as people have become more conscious of what agents can do, they are asking agents to perform tasks, rather than simply answer questions.

“Now what you’re starting to see people do is very action oriented. So instead of asking ’how do I file a form to request my vacation’ from our employee agent, they’re telling the employee agent, ‘hey I’m taking a vacation, you need to enter this form for me, and here’s the details,’” he said, adding that this bias towards action represents the evolution of agentic use.

A Canadian hacker has admitted being part of a group responsible for several major cyberattacks. Connor Riley Moucka pleaded guilty to being part of a coterie of hackers that hit 165 organizations, resulting in the theft of customer records and the extortion of millions of dollars.

Industry sources have identified Moucka as one of the main players in attacks on data hosted by cloud data warehouse Snowflake. Companies affected by the hacks include the likes of AT&T, Ticketmaster and the Neiman Marcus Group.

He worked with two other hackers: John Edward Binns and Cameron John Wagenius. Binns was not in US custody as of April 2026, while Wagenius, going by the name of Kiberphant0m, was arrested in January 2025 and pleaded guilty in July that year

Moucka and other members of the group used stolen login credentials to compromise data belonging to at least 165 customers of a US-based software-as-a-service company. This unauthorized access was used to steal billions of sensitive customer records and download terabytes of information,

“Connor Moucka hacked over 150 companies and organizations, obtained extremely sensitive information, and extorted the victims for millions of dollars. Today’s guilty plea serves as a reminder to all cybercriminals, regardless of where they live, that they cannot hide behind a wall of anonymity. You will be found and brought to justice,” said assistant attorney general A. Tysen Duva of the Justice Department’s Criminal Division

The trial is the result of a coordinated worldwide action against the Snowflake group. The investigation was led by the FBI but benefited from contributions from the Royal Canadian Mounted Police, the Australian Federal Police, Spain’s Guardia Civil, the Security Service of Ukraine and the Turkish National Police.

This article first appeared on CSO.

There’s something very attractive about saying “we embed very closely with our customers and just figure it out with them”, especially since the company that started “forward deploying engineers” is growing 84% with $5B+ revenue. But “forward deployed engineer” is a vague term and means different things depending on the business you’re running.

I spent almost 5 years at Palantir as a forward-deployed software engineer, and Palantir’s version of an “FDE” does not make sense for most companies I now meet as an early-stage VC. Depending on the type of business you’re building, this role could broadly mean one of two things: “the product builder” or “the platform operator.” Clearly defining which bucket you fall into will make it easier to hire for this role and run your FDE org.

Kabir Sial

The product builder: The OG Palantir version

The north star is: do whatever it takes to actually solve the user’s problem. FDEs are not just responsible for making the platform work, but also discovering what to build and building it (actually creating software) in service of the customer.

The platform operator: Solutions + technical customer success

The north star is: make the product work for the customer – deploy and operationalize it. This is what most startups today really mean when they want FDEs. FDEs here configure the core platform, manage account relationships and drive adoption. This is not new – companies have always had solutions engineers, sales engineers, customer success etc., although the work looks different as FDEs are increasingly building prototypes, configuring evals and building MCPs.

Which FDE is right for you

Kabir Sial

For most situations, hiring product builder FDEs is a mistake.

At scale, the FDEs should be the platform operator. It’s hard to have FDEs build and maintain highly custom product features, especially as the company scales. Over time, the custom product surface area distracts from building the core product, even though AI coding tools make it easy to ship new features quickly and maintain them.

Many fast-growing AI startups recognize these constraints and structure the FDE role more like the platform operator. This also allows them to have 5-10 accounts per FDE, which is a much higher ratio than Palantir had (at least in 2023). Even the Palantir FDE role has evolved to look more like the platform operator.

There are, however, situations when your FDEs should be the product builder archetype.

1. You have very large customers (F500 scale)

Technical complexity: Large customers have complex environments with legacy infrastructure that often requires “out-of-platform” engineering work. I often encountered bespoke data infrastructure, privacy requirements, etc. at various Palantir customers that required me to build “out-of-platform” connectors, UIs and backends.

Organizational inertia and trust: Serving large enterprises is about building trust. In short time periods, overfitting product to a specific user/workflow is often what delivers the most value, builds trust and helps organizations get over the inertia of moving away from Excel and legacy software tools that are part of their day-to-day workflow. For AI-native startups, it’s arguably even more important to invest in doing “unscalable” development with engineering boots on the ground, as it helps solidify your right to exist and eventually expand the customer relationship.

2. You have many ICPs and workflows

If you have a broad range of ICPs and workflows that you serve, your product probably is not walk-up usable on day 1 of deployment. The short-term hacky things that product builder FDEs build to make the product work for these heterogeneous users/workflows will help you shape the product long-term.

Kabir Sial

Note: see Palantir Foundry’s architecture here.

This was a big reason why Palantir FDEs were more like product builders (and are still able to – see the Forward Deployed Software Engineer job profiles as an example). The vision for Foundry was to be the operating system for an enterprise’s critical decisions – inherently multiple industries, users and workflows. A lot of FDE-led development showed that solving many of these use cases required complex data integrations, which led to the early versions of Foundry being best-suited for complex data integrations and building a customer’s “Ontology”. Similarly, FDEs like myself built custom frontend applications for fraud analysis, pricing, etc. As certain patterns of what these applications required became more clear, they were centralized into an application-layer product.

Who you should hire

Kabir Sial

Kabir Sial

Platform operator: There is a much broader set of people you could hire, testing for technical fluency (e.g., being good at data analysis, complex Excel work, even SQL), product intuition and an inclination to build customer relationships. Backgrounds like technical customer success, solutions engineering, software engineering, product management and consulting are all strong fits.

Product builder: You want candidates that are high ownership and missionary software engineers, or technical PMs who want to ship products themselves.

Hiring for these profiles, especially product builders, is hard. It’s worth calling out two things that helped Palantir hire software engineers into what might be considered a less sexy role.

1. Culture of building at the edge: Strong engineers are motivated to build things. Palantir gave FDEs a lot of ownership to build products, which is why much of the core product leadership was former FDEs.
2. Cult built around mission: Internally, there was a cult-like devotion to the mission. Everyone always talked about why outcomes were far more important than software, and why most companies building tools had it wrong. I’ve never been at a company where people feel so closely bonded around a mission.

As founders building AI startups think about hiring FDEs, it’s worth being specific about your culture and asking: Am I just hiring people to support development teams, or am I hiring people to shape and build product? It’s hard to get software engineers (even today) to be excited about an FDE role that might just be technical customer success.

What FDEs should be doing (regardless of archetype)

You’ve hired the right people. How do you best leverage your team of FDEs?

FDEs were Palantir’s way of delivering outcomes rather than tools. AI-native startups can take this much further and FDEs can help in a few unique ways by leveraging their proximity to customers.

1. Find the most critical workflows: As AI lowers the cost of producing software, companies will face a lot more competition. FDEs at AI startups should be constantly finding ways to serve the most critical workflows for a customer and paying attention to how customers do work across newer and legacy tools. For example, FDEs at Harvey should pay attention to which workflows are in Westlaw, which ones are moving to ChatGPT/Claude, and how the Harvey product can stay ahead.
2. Build around nondeterminism: In more regulated environments, FDEs should be hyper-focused on making products reliable for specific use cases using evals and configs. Previously, product reliability lived with product and support. As companies provide outcomes instead of tools, configuring products appropriately and managing evals shifts towards FDE teams.

As enterprises look for ways to cut the cost of running AI models in production, AMD is betting that not every AI workload will be best served by a power-hungry general-purpose GPU.

AMD has agreed to buy Taalas, the Canadian designer of chips that permanently embed a trained AI model’s weights into custom silicon, instead of repeatedly loading them from memory during inference as conventional GPUs do.

Taalas says its approach reduces the time and power required to move model weights between memory and compute units, making things run faster and cheaper.

The result is a highly specialized inference processor optimized for one model, trading the flexibility of programmable hardware for substantially higher throughput and energy efficiency.

Operational tradeoffs

While AMD is planning to integrate the chips into its Instinct GPU roadmap, targeting system-level AI inference solutions in data centers, analysts remain skeptical that enterprises will readily embrace hardware tied to a specific AI model.

Enterprises would, effectively, be buying a chip and a model together because unlike GPUs, which can be repurposed to run different AI models through software updates, Taalas’ chips are tied to a specific trained model, meaning they would need different hardware to support different inference tasks, said Amit Kumar Jena, AI development manager at IT Consulting firm Kanerika.

Or as Forrester Principal Analyst Charlie Dai put it, “The biggest risk is inflexibility.”

The requirement to swap hardware in order to swap tasks would, Dai said, introduce new challenges with costs, governance, capacity planning, lifecycle management, and supplier dependency, especially for enterprises managing multiple AI workloads.

Manoj Chandra Jha, principal analyst at Nord-IQ Research, said the risk of fusing chip and model into one component is larger than one might think, as “early model obsolescence strands both together, so this should be modeled as one shorter-lived asset rather than two independently amortized ones.”

Taalas says it can update a model by modifying only two metal layers of the chip rather than redesigning it from scratch, but that will only apply to chips that haven’t yet left its factory, not those already in use.

That means enterprises will still need to plan for hardware refresh cycles measured in weeks or months and retain programmable GPUs for workloads that evolve frequently, said Pareekh Jain, principal analyst at Pareekh Consulting.

It also means, said Jha, that what is typically a software decision becomes one about capital expenditure for Taalas customers, as replacing or switching workloads or models could require investing in new hardware rather than simply updating software.

Where model-specific silicon fits

Those tradeoffs significantly narrow the range of enterprise workloads where model-specific silicon is likely to make economic sense.

Dai sees the technology as best suited for mature, predictable inference workloads that run at massive scale and rely on relatively stable AI models, such as customer service automation, fraud detection, industrial computer vision, network operations, edge AI, and embedded copilots.

For CIOs, that effectively limits model-specific silicon to a small subset of enterprise AI deployments, rather than a wholesale replacement for GPU infrastructure, he said. “GPUs will remain the preferred enterprise platform because most enterprises value flexibility, multi-tenancy, and rapid model evolution over maximum efficiency.”

This article first appeared on Network World.

Business application development is entering a new operating model. The traditional approach of gathering requirements, designing screens, writing services, integrating systems, testing, fixing defects and preparing release documentation still exists, but it is no longer sufficient for enterprises that need speed, traceability, resilience and regulatory confidence at the same time. Hyperautomation brings a broader discipline to this challenge. It combines workflow orchestration, intelligent document processing, robotic automation, API-led integration, process mining, test automation, observability and artificial intelligence into a connected delivery fabric. With embedded Generative AI, this fabric becomes more adaptive because applications can interpret natural language, summarize complex data, generate explanations, detect exceptions and support decision workflows rather than merely execute predefined rules.

In banking, this shift is especially meaningful. Banks operate across dense application landscapes: trade reporting platforms, wealth management portals, core banking systems, investment banking applications, digital compliance engines, reconciliation utilities, operational dashboards, audit repositories and daily, weekly and monthly reporting platforms. Each of these areas has its own data models, control points, integration patterns, validation rules, exception paths and regulatory obligations. Hyperautomation does not replace engineering discipline; it strengthens it by making business intent, technical execution, control evidence and continuous improvement part of the same lifecycle.

From automation to hyperautomation in banking applications

Automation usually addresses a specific task: moving data from one system to another, generating a report, running a batch job or validating a transaction against a rule. Hyperautomation goes further. It looks at the complete business outcome and asks how the entire chain can be streamlined, governed, observed and improved. For example, a trade reporting process may begin with transaction capture, enrich the trade with reference data, validate regulatory fields, identify breaks, generate a submission file, transmit it to a regulator or trade repository, monitor acknowledgements and preserve audit evidence. A narrow automation script may accelerate one step, but a hyperautomated design coordinates the complete flow, including exception handling and evidence generation.

Magesh Kasthuri

Figure: Automation vs. hyperautomation

Embedded Generative AI adds a new layer of intelligence. Instead of forcing every user interaction into rigid screens and codes, business applications can accept natural language prompts, interpret document content, summarize cases, generate draft responses, explain anomalies, produce test scenarios and create release notes. In a banking environment, this intelligence must be carefully bounded. Every AI-assisted action should be traceable, explainable, reviewable and aligned with data privacy, model risk, information security and regulatory expectations. The goal is not uncontrolled autonomy; the goal is governed acceleration.

Banking application components suitable for hyperautomation

A modern banking application is rarely a single monolithic system. It is a composition of business capabilities, integration services, workflow engines, data pipelines, user experience layers, analytics models, control dashboards and audit stores. Hyperautomation can accelerate the development and integration of these components by turning repetitive engineering work into reusable patterns and by embedding intelligence directly into business processes.

• Trade reporting applications: Generative AI can help map trade attributes to regulatory fields, explain validation failures, summarize rejected submissions and generate test cases for reporting scenarios. Hyperautomation can orchestrate enrichment, validation, submission, acknowledgement tracking and evidence archival.
• Wealth management platforms: Advisors can use embedded AI to summarize client portfolios, generate suitability narratives, identify missing documents and prepare personalized investment review notes. Automation can coordinate onboarding, risk profiling, document verification, portfolio rebalancing workflows and client communication approvals.
• Core banking applications: Account opening, loan servicing, deposits, payments, interest calculations and customer maintenance can benefit from automated validations, intelligent forms, workflow routing and natural language assistance for operations teams. AI can explain account events or transaction exceptions in plain language.
• Investment banking systems: Deal pipelines, research workflows, underwriting processes, trade lifecycle functions and risk calculations require strong coordination across front-office, middle-office and back-office platforms. Hyperautomation can standardize approvals, documentation, exception resolution and control evidence across these stages.
• Digital compliance applications: Compliance teams can use AI to summarize policy obligations, compare regulatory changes with internal controls, classify alerts, draft investigation notes and produce evidence packs. Automation ensures routing, approvals, segregation of duties, audit trails and regulatory reporting timelines are consistently enforced.
• Reconciliation platforms: AI can assist in matching narratives, explaining breaks, clustering exception patterns and suggesting resolution actions. Hyperautomation can pull data from ledgers, statements, payment processors, trading systems and data warehouses, then route unresolved breaks to the right teams.
• Reporting and audit applications: Daily, weekly and monthly reports can be generated through controlled data pipelines, automated quality checks, narrative generation, variance explanations and approval workflows. Audit applications can preserve lineage, approvals, source extracts, model outputs and control attestations.

Embedded generative AI as an application capability

Embedding Generative AI into business applications should be treated as an architectural capability, not as a decorative chatbot. A banking application may use AI for search, summarization, reasoning support, content generation, code generation, policy interpretation or anomaly explanation. Each use case requires clear boundaries. The application must know which data the model can access, which actions require approval, what evidence must be captured and where deterministic controls must override probabilistic suggestions.

For example, in trade reporting, an embedded AI assistant can explain why a transaction failed validation and suggest likely fields to review. However, the final correction should pass through rule-based validations, maker-checker approval and audit logging. In wealth management, AI may draft a client review note based on portfolio movements and risk profile, but the advisor must verify suitability, disclosures and final communication. In reconciliation, AI can propose likely matches or categorize break reasons, while the system preserves the original data, confidence score, reviewer action and final resolution path.

Hyperautomating the product development lifecycle

The Product Development Lifecycle can itself become hyperautomated. Instead of treating ideation, analysis, design, development, testing, security review, release and operations as disconnected phases, enterprises can create an AI-assisted delivery loop where every stage produces structured artifacts that the next stage can consume. Platforms such as GitHub Copilot, Claude Code or Claude Cowork-style agentic development environments and OpenAI Codex can support this movement by helping teams reason over requirements, generate code, create tests, review changes, modernize legacy modules and produce documentation. Their value increases when they are connected to repositories, issue trackers, design documents, build pipelines, test suites, security scanners, observability data and enterprise knowledge bases.

Role of GitHub Copilot, Claude Cowork and Codex

GitHub Copilot is useful where developers need assistance inside the engineering flow: explaining code, generating functions, proposing tests, reviewing pull requests and helping teams move from issue to implementation. In a banking PDLC, it can accelerate microservice creation, API integration, batch processing logic, reconciliation rules, regulatory validation routines and UI workflows. When used with repository context and proper review discipline, it can reduce the time developers spend on repetitive coding while preserving human accountability for design and correctness.

Claude Cowork or Claude Code-style agentic environments are valuable for multi-file reasoning, refactoring, debugging and documentation-heavy engineering work. Banking applications often contain deep domain logic scattered across services, configuration files, stored procedures, integration scripts and test suites. An agentic coding assistant that can understand a wider codebase context can help engineers analyze dependencies, prepare modernization plans, update multiple files coherently and draft explanations for reviewers. This is particularly useful in core banking modernization, trade reporting rule updates and compliance workflow refactoring.

OpenAI Codex can support issue-to-pull-request workflows, test generation, code review, bug reproduction, migration activities and broader software engineering tasks across the lifecycle. In a hyperautomated PDLC, Codex-like agents can be assigned well-scoped work items, asked to inspect failing tests, propose fixes, create regression coverage and summarize the change for human reviewers. The important design principle is to keep agents inside controlled boundaries: clear prompts, repository permissions, test gates, approval workflows and traceable outputs.

Integration architecture for hyperautomated banking applications

A practical architecture begins with business capability decomposition. Each banking domain should be expressed as a set of bounded capabilities such as customer onboarding, account maintenance, trade enrichment, exception management, portfolio review, control attestation, report generation and audit retrieval. These capabilities should be exposed through APIs, events, workflow tasks, data products and user interfaces. Hyperautomation then connects these capabilities using orchestration engines, event streams, rules engines, AI services, RPA connectors where legacy integration is unavoidable and observability layers that capture business and technical telemetry.

The embedded AI layer should sit behind a secure application service boundary. It should use retrieval-augmented generation where approved policies, product rules, application documentation and regulatory mappings are retrieved from trusted sources. It should avoid uncontrolled exposure of sensitive customer information. Prompt templates, response validation, redaction, grounding checks, model monitoring and human-in-the-loop approval should be part of the production design. In banking, the most successful AI pattern is often not full automation but assisted decisioning with strong controls.

Example: Hyperautomated reconciliation and reporting flow

Consider a reconciliation application that compares ledger balances, payment files, trade settlement records and external statements. In a conventional model, operations teams spend significant time downloading files, running macros, investigating mismatches, documenting break reasons and preparing status reports. In a hyperautomated model, data ingestion is scheduled and monitored, schema checks run automatically, matching engines classify obvious matches, AI assists with ambiguous narratives, exceptions are routed through workflow queues and dashboards update in near real time. At the end of the day, the system can generate a draft operations report explaining unresolved breaks, aging trends, risk exposure and pending approvals.

The same pattern can extend to daily, weekly and monthly reporting. Data quality rules validate inputs, report templates are populated automatically, AI generates narrative commentary on variances, reviewers approve or amend explanations and the final report is archived with lineage and approvals. Audit teams can later retrieve not only the report but also the source extracts, transformation logs, exception history, reviewer decisions and AI-generated drafts. This creates a richer control environment than manual reporting because evidence is captured by design rather than reconstructed later.

Governance, risk and control considerations

Hyperautomation in banking must be designed with governance from the beginning. The development team should define which activities can be automated, which can be AI-assisted and which must remain under human approval. Source code generated by AI must pass normal engineering controls, including peer review, static analysis, dependency scanning, secure coding checks, test execution and production readiness review. Business outputs generated by AI, such as compliance narratives or client-facing explanations, should be reviewed where regulatory or reputational risk is material.

Data governance is equally important. AI-enabled applications must respect data classification, residency, retention, masking and access policies. The model should not become an uncontrolled channel through which confidential customer, trading or employee information can leak. Every prompt, retrieved source, generated response, user action and final decision may need to be logged depending on the use case. For audit applications, this traceability is not optional; it is the foundation of trust.

Operating model for AI-native PDLC

A hyperautomated PDLC requires changes in team behavior. Product owners should write requirements in a structured manner so that AI tools can generate better stories, acceptance criteria and test scenarios. Architects should maintain living decision records, reference patterns and integration standards that AI agents can use as context. Developers should learn prompt discipline, context packaging and review techniques. Test engineers should focus on coverage strategy, synthetic data, compliance scenarios and defect prevention rather than only manual execution. Operations teams should feed incident learnings back into the backlog so the system improves continuously.

The role of human experts becomes more important, not less. AI can draft, generate, compare and suggest, but domain judgment remains essential. A trade reporting specialist understands regulatory nuance. A wealth advisor understands client suitability. A core banking architect understands transaction integrity. A compliance officer understands control interpretation. Hyperautomation works best when it amplifies these experts and removes repetitive friction around them.

Conclusion

Hyperautomation in business application development is not simply a faster way to write software. It is a new way to connect business intent, engineering execution, operational control and continuous learning. In banking, where applications must be reliable, explainable, secure and compliant, the combination of embedded Generative AI and disciplined automation can transform how applications are designed, built, integrated, tested, released and operated. Trade reporting, wealth management, core banking, investment banking, compliance, reconciliation, reporting and audit functions can all benefit when AI is embedded responsibly and automation is orchestrated across the complete lifecycle.

Platforms such as GitHub Copilot, Claude Cowork or Claude Code and OpenAI Codex can play an important role in this transformation by accelerating analysis, development, testing, review, modernization and documentation. Their greatest value appears when enterprises treat them not as isolated productivity tools but as part of a governed, AI-native PDLC. The future of banking application development will belong to teams that can combine human expertise, reusable engineering patterns, intelligent automation and strong governance into one coherent delivery model.

This article was made possible by our partnership with the IASA Chief Architect Forum. The CAF’s purpose is to test, challenge and support the art and science of Business Technology Architecture and its evolution over time as well as grow the influence and leadership of chief architects both inside and outside the profession. The CAF is a leadership community of the IASA, the leading non-profit professional association for business technology architects.

As an aviation industry veteran with over 30 years of experience, Alaska Airlines CIO Charu Jain is all too familiar with the technology integration process that often follows a big airline merger.

By her count, she’s been involved in four such projects. But none, she says, has brought her greater satisfaction than leading the overhaul of Alaska’s PSS following its $1.9 billion acquisition of Hawaiian Airlines in September 2024.

“This is one of the biggest milestones in any merger work done between airlines,” says Jain, speaking from her company’s Seattle offices just two months after Alaska and Hawaiian completed their transition to a shared PSS.

In its simplest terms, a PSS is an all-encompassing software suite used by airlines to record and manage a passenger’s journey, from booking tickets and checking in baggage at the airport, to boarding the aircraft and accessing the in-flight menu. “A PSS touches almost every function of an airline from employees to guests,” says Jain.

Two brands, one system

At the time of the merger, Alaska and Hawaiian each had its own PSS. No sooner had the ink dried on the deal than the cutover project got underway to bring both airlines’ systems under a single operating platform.

According to Jain, the two airlines agreed from the get-go that they’d retain their own unique historic brands, both with a combined history of close to 200 years, which would be reflected through the system.

“It had never been done before, developing capabilities to enable two brands on one platform,” adds Jain, who also serves as Alaska’s SVP of merchandising and innovation. “We didn’t want a situation where a passenger travelling from Spokane to Seattle on an Alaska-branded flight, and then onto Honolulu on a Hawaiian-branded flight, would have to navigate two separate systems. So we thought about how to make that experience more seamless.”

After settling on a PSS, developed by travel software manufacturer Sabre, Jain and her colleagues began work on migrating the airlines’ millions of bookings and passenger information, while also updating their various guest- and employee-facing tools for the new system.

Selling cutovers and mock flights

Executing a system cutover on such a large scale is a delicate balancing act, not least in a live-environment where, for a major airline, any form of disruption to the passenger experience can be bad for business. So there was no attempt to rush the project.

“To make sure we didn’t have any issues with customers’ bookings, we really took a risk-optimized approach with a phased deployment and a phased cutover,” says Jain.

Much of this hinged on what Alaska refers to as a selling cutover. Starting in October last year, all new bookings were made on the new PSS, which allowed the group to drain old bookings from the legacy system, and start selling tickets six months in advance of the official transition date; the average booking curve for an airline is around six months.

“There was no migration of millions of records and bookings,” says Jain. “This meant when our customers checked in on the first day [of the PSS], it was as if the booking had been made on the native system.”

While this was going on, however, Alaska was hit by a sizeable IT outage that grounded flights across the country and impacted the travel plans of nearly 50,000 passengers. It followed a previous IT outage in July. However, Jain says the disruptions didn’t impact the project in any way.

So in the final months leading up to the cutover completion, Alaska carried out several dress rehearsals to test the system, including mock flights for domestic and international routes in anticipation of the recent launch of several non-stop services to Europe.

This involved real guests arriving at the airport, completing check-in, going through security, and taking their seats as if they were about to take off. Leaving no stone unturned, the simulation also accounted for baggage collection, pets, wheelchair users, and onboard hospitality, stopping just short of passengers being served actual food.

Alaksa completed five such mock rehearsals in all. “The fifth one was when everything worked without any medium or high issues, and gave us the confidence we were ready,” says Jain.

As part of the airline’s scenario planning, it also set up command centers in various locations, including Honolulu and Seattle, to plan for unforeseen and unrelated problems on the day of the cutover.

A dedication to collaboration

A project is only ever as a good as its people, and Jain is quick to hail the collaborative spirit that Alaska and Hawaiian brought to the table. As a PSS involves both the operational side of an airline’s business — touching on everyone from pilots, flight attendants, and baggage handlers — and commercial departments responsible for policies and pricing, this was more than a purely technological undertaking.

“This was about people coming together from two companies to make this one big thing happen,” says Jain.

When Alaska started making bookings on the new PSS last fall as part of the selling cutover, it also began training employees how to use system. It was around that time as well, says Jain, that the airline was confident the transition would be completed by April 2026, just in time for the busy summer travel season.

Since the PSS has been up and running, the company has also introduced a single mobile app to replace Alaska and Hawaiian’s separate existing ones, allowing passengers to personalize their experience to the airline brand they’re more familiar with.

“It’s a much more seamless experience now that there’s no confusion knowing which app to go on, or why they have two booking numbers,” says Jain. Alaska’s employees are also just as happy with their new tools, she adds.

As enterprises look for ways to cut the cost of running AI models in production, AMD is betting that not every AI workload will be best served by a power-hungry general-purpose GPU.

AMD has agreed to buy Taalas, the Canadian designer of chips that permanently embed a trained AI model’s weights into custom silicon, instead of repeatedly loading them from memory during inference as conventional GPUs do.

Taalas says its approach reduces the time and power required to move model weights between memory and compute units, making things run faster and cheaper.

The result is a highly specialized inference processor optimized for one model, trading the flexibility of programmable hardware for substantially higher throughput and energy efficiency.

Operational tradeoffs

While AMD is planning to integrate the chips into its Instinct GPU roadmap, targeting system-level AI inference solutions in data centers, analysts remain skeptical that enterprises will readily embrace hardware tied to a specific AI model.

Enterprises would, effectively, be buying a chip and a model together because unlike GPUs, which can be repurposed to run different AI models through software updates, Taalas’ chips are tied to a specific trained model, meaning they would need different hardware to support different inference tasks, said Amit Kumar Jena, AI development manager at IT Consulting firm Kanerika.

Or as Forrester Principal Analyst Charlie Dai put it, “The biggest risk is inflexibility.”

The requirement to swap hardware in order to swap tasks would, Dai said, introduce new challenges with costs, governance, capacity planning, lifecycle management, and supplier dependency, especially for enterprises managing multiple AI workloads.

Manoj Chandra Jha, principal analyst at Nord-IQ Research, said the risk of fusing chip and model into one component is larger than one might think, as “early model obsolescence strands both together, so this should be modeled as one shorter-lived asset rather than two independently amortized ones.”

Taalas says it can update a model by modifying only two metal layers of the chip rather than redesigning it from scratch, but that will only apply to chips that haven’t yet left its factory, not those already in use.

That means enterprises will still need to plan for hardware refresh cycles measured in weeks or months and retain programmable GPUs for workloads that evolve frequently, said Pareekh Jain, principal analyst at Pareekh Consulting.

It also means, said Jha, that what is typically a software decision becomes one about capital expenditure for Taalas customers, as replacing or switching workloads or models could require investing in new hardware rather than simply updating software.

Where model-specific silicon fits

Those tradeoffs significantly narrow the range of enterprise workloads where model-specific silicon is likely to make economic sense.

Dai sees the technology as best suited for mature, predictable inference workloads that run at massive scale and rely on relatively stable AI models, such as customer service automation, fraud detection, industrial computer vision, network operations, edge AI, and embedded copilots.

For CIOs, that effectively limits model-specific silicon to a small subset of enterprise AI deployments, rather than a wholesale replacement for GPU infrastructure, he said. “GPUs will remain the preferred enterprise platform because most enterprises value flexibility, multi-tenancy, and rapid model evolution over maximum efficiency.”

Wispr, the startup behind dictation tool Wispr Flow, has created an AI note-taking assistant that records meetings and generates conversation summaries for users.

The Wispr Flow Notetaker tool “captures your meetings so you can stop splitting your attention between listening and writing things down,” said Sahaj Garja, Wispr CTO and co-founder.

Notetaker starts recording with one click, and doesn’t require a bot to attend a video or voice call. It can also be used to capture in-person conversations.

The software has three key functions. Before a call, Notetaker displays a meeting brief with information such as meeting purpose and background of participants.

Once the meeting starts, a live transcript displays the dialogue text and labels speakers. A “what did I miss?” button provides a summary of talking points from the previous few minutes.

Finally, post-meeting, Notetaker generates a more detailed summary organized by topic that includes information such as key dates, decisions, and next steps. Users can search across notes from previous meetings in the Notetaker app. “Over time your meeting history stops being a folder of documents you have to go find and becomes something you can ask questions of,” said Garja.

Notetaker integrates with AI assistants such as Anthropic’s Claude and OpenAI’s ChatGPT via model context protocol. This allows users to connect outputs such as transcripts and summaries “into how you already work, instead of sitting in a separate app,” said Garja.

With Notetaker, Wispr competes in an increasingly busy market for AI note-taking apps that includes Fireflies, Granola and Otter.

Wispr claims Notetaker can produce more accurate transcripts than existing tools, partly because of the additional context it uses during transcription. It uses the same personal dictionary from Wispr Flow that includes acronyms, products, and preferred spellings, and can also draw on other sources such as calendar information to understand the purpose of a meeting and help ensure speakers are labelled correctly.

Before generating the final summary, Notetaker also re-reads the live meeting transcript and combines it with additional context to create a more accurate final output, Garja said.

Notetaker is the first new product launched by Wispr, which was founded in 2021 and has since raised $81 million in funding.

“We didn’t set out to build a dictation app,” said Garja. “The mission has always been to reshape how people interact with their devices, and dictation was the fastest way in.”

“Notetaker is the second product on that path. Dictation took the keyboard out of writing. Notetaker takes it out of meetings, so nobody has to spend the call typing up what everyone just said.”

User consent when recording calls

As AI note-taking tools have become more prevalent in the workplace, privacy concerns have arisen, including the need for all-party consent when recording a call in some jurisdictions, and whether meeting audio is used to train AI models. Two software vendors, Otter and Granola, currently face separate lawsuits in California that allege privacy law violations related to their products.

Wispr Flow Notetaker captures audio locally on a user’s device rather than joining the call as a visible bot. That means there’s no notification to signal that a conversation is being transcribed, which places responsibility on users to disclose the recording to others on the call in accordance with local laws, said Garja.

“Users should always let the other person know before you start recording or transcribing a conversation, whether it’s a video call, an in-person meeting, or a phone call,” he said, adding that Wispr intends to build additional features for automated consent messaging “in the coming weeks.”

Wispr doesn’t train its AI models on customer data without consent, though free and standard tier customers must choose to opt-out, according to Wispr’s privacy terms. Nor does it create “voiceprints or biometric profiles” of users or anyone else on a call using audio recording data, the company says.

When Notetaker is active, conversation audio is captured on a user’s device and processed on cloud servers to enable transcription. The recorded audio file is encrypted and stored temporarily on the user’s device or cloud storage, Wispr said. After a limited period, the audio is automatically deleted.

Notetaker is available with the Wispr Flow macOS app to free and paid subscribers, with support for Windows “coming soon.”

It’s no secret that the CIO role is changing in Canadian enterprises. Driving operational performance and increasing efficiency are, of course, still a big part of the job. But CIOs are now expected to do more than cut costs and keep the lights on. Increasingly, boards of directors expect the CIO to play a key role in creating value and enabling their organizations to outperform their rivals. Recent data backs this up. The overwhelming majority (91%) of Canadian technology leaders believe advanced technology will be the primary driver of competitive advantage over the next three years, according to KPMG’s “The 8 execution imperatives for Canadian tech leaders,” a white paper based on the firm’s 2026 Global Tech Report.

The race to capture value from emerging technologies has intensified, leaving little room for organizations that remain on the sidelines. Yet in Canada, just 27% of organizations consider themselves innovators or early adopters, while 72% are fast or slow followers. Nearly all (85%) believe they’ll need to take more risks with emerging technologies just to remain relevant.

The traditional, operational-first mindset among CIOs has become a liability. CIOs are expected to be strategic players, but meeting that expectation requires taking thoughtful, well-considered action across key imperatives.

AI success depends on data

AI is not the only advanced technology that organizations are working to deploy, but it’s certainly garnering the most attention from C-suite executives, boards of directors, and investors. To enable AI at scale, the data foundations enterprises have built over the past decade will be necessary, but they are not sufficient on their own. CIOs must make modernizing the state of enterprise data a top priority.

In most large organizations, data often remains locked inside legacy systems where the system of record is also the system of engagement, and that significantly limits accessibility for AI workloads. Data should be treated as the strategic asset that it has become. The quality, timeliness, and governance of that data vary widely, and reconciling those inconsistencies is one of the most persistent barriers to enterprise-level deployment.

Scaling pilots into enterprise programs also requires closing the gap between AI-native talent, who have the skills to move quickly, and those with deep institutional knowledge, who understand how their organizations work and what they need to achieve. These two groups must work hand in hand. Otherwise, organizations may accelerate toward the wrong goals, which won’t move the business forward.

“The barriers to scaling AI aren’t just technical,” says Sanjay Pathak, partner and national leader, technology strategy and digital transformation services, KPMG Canada. “CIOs need to truly and deeply understand the value chain of what their organizations do. Those who get there will have the imagination, the courage, and the foresight to use AI to transform their organizations.”

Communicating ROI requires the right framing

Beyond scaling, simply communicating the value of AI also poses a significant challenge. Just over half (53%) of Canadian organizations surveyed say they struggle to demonstrate or communicate AI value to stakeholders. Part of the problem is that CIOs are making the wrong argument in the wrong room because they’re framing ROI as a technology metric rather than a business outcome.

“Any CIO who doesn’t truly understand what their business does is missing a beat around how innovation is going to help the organization achieve ROI,” says Pathak. “Understanding how to deploy AI inside your value chain will give you a head start and a competitive advantage in unlocking real business benefits.”

A formal performance measurement framework that tracks customer experience, revenue growth, and employee adoption alongside cost metrics gives CIOs a far more accurate picture of long-term value. Linking funding decisions to those strategic outcomes makes sustained investment easier to justify.

There is also a compliance dimension that often goes unacknowledged in these conversations. CIOs who bring business, technology, and compliance leaders together to design innovative processes that are “compliant by design” from the start are protecting future value as much as they are delivering value today.

“You need to assemble that multi-dimensional cohort of business, technology, risk, and compliance leaders at the same table, envisioning compliance by design,” says Pathak. “The winners in this space are going to be the ones who really think about business ambition holistically and focus on efficient delivery, operations, and compliance.”

Building disciplined innovation governance

An organization’s approach to governance makes an enormous difference in how quickly and confidently it can deploy and take advantage of advanced technologies. As noted above, almost three-quarters (72%) identify as fast or slow followers, and 85% say they need to move more aggressively to embrace new technologies. Canadian organizations aren’t lacking ambition. What they lack are the conditions required to innovate with confidence: clear ownership, defined risk thresholds, and shared accountability between technology, risk, and business teams.

“You can be an innovator, but if your innovation is not directly connected to strategic business ambition and safety guardrails such as risk management, governance, and compliance, you’re creating labware,” says Pathak. “Being an early adopter means you’re comfortable with the technology. To make it truly viable, you must embrace all dimensions of enterprise value.”

Strong governance does not slow innovation down but instead provides a structure that builds confidence and resilience at every level of the organization, from the board to project teams. A tiered governance approach that takes risk into account allows organizations to advance low-risk, incremental improvements and high-reward initiatives in parallel.

Expanding partnerships to accelerate innovation

Innovation isn’t a single-player game, and Canadian organizations know it. Ninety-seven percent of respondents say they plan to expand their external ecosystems. To date, a significant portion of those relationships have been transactional and focused on a specific capability or problem. But savvier organizations are moving toward multi-party innovation, where partners pool capabilities to share both risk and reward. This model requires a different kind of commitment because organizations are betting on a partner’s long-term viability, not just their current capability. Together, they must build the integration and governance infrastructure that makes these ecosystems work for all participants.

“Moving to multi-party innovation ecosystems is an investment in integration and data,” says Pathak. “If you’re going to look at best of breed and stitch those together, what must be true for that to work is the ability for those different ecosystems to integrate and interoperate. And that creates a much stronger need for safety and governance.”

Cybersecurity is another dimension that grows more important with every new partner added to the ecosystem. Security should be proactively built in, not imposed after a breach has already occurred.

“The more ecosystem-based partnerships you have, the more opportunity you create along with the threat you have to deal with,” says Pathak. “You expand the attack surface, and you become more of a target, so governance and cybersecurity must be designed in from the start, not bolted on later.”

Canadian government incentives, including Scientific Research and Experimental Development (SR&ED) tax credits and AI-focused clusters, offer a way to share some of the cost and risk, particularly during periods of economic uncertainty.

By leveraging these funding frameworks alongside robust ecosystem governance, forward-thinking organizations can safely scale their networks to turn shared risks into sustainable competitive advantages.

In closing

For organizations navigating this environment, KPMG Canada emphasizes that the most consequential decisions ahead are not purely, or even mostly, technical. They are about how CIOs choose to lead, partner, measure, and govern in a period that rewards both ambition and discipline in equal measure.

The data points are clear. CIOs who lead with both strategic ambition and disciplined execution will elevate their organizations above their competitors. By paying attention to the quality of their data, aligning technical priorities with critical business goals, and instituting strong governance and cybersecurity, they will set a higher standard for what Canadian competitiveness looks like in the years ahead.

To learn more, read the full whitepaper: The Top 8 Execution Imperatives for Canadian Tech Leaders.

Salesforce customers more than doubled their agentic workforces year on year, according to the company’s second annual Agentic Enterprise Index, which looks at trends in AI agent development and deployment over the past five quarters.

It compiled data from customers who had activated agents in production every month of the analysis period to determine how their use of the technology has evolved between February 2025 and April 2026, as well as incorporating data from May 2026 Salesforce research studies.

It found that businesses grew their agentic workforces from an average of five agents in February 2025 to 13 by April 2026, a 7% compound monthly growth rate (CMGR). In April 2026, it only took an average of 1.9 days to deploy an agent into production, a 53% decrease since the beginning of the report period.

Not only were agents deployed more quickly, they have been progressively taking on more work once in use; over the 15 months, the average number of actions per account had a CMGR of 31%.

“These agents are expanding beyond their initial scope to really become cross-functional,” said Caila Schwartz, Salesforce’s head of agentic commerce insights, during a media briefing.

Salesforce has attempted to measure how much work agents perform, rather than how many tokens they consume, creating its own Agentic Work Unit (AWU) metric, although analysts have criticized the measure as being unrelated to business outcomes. Nevertheless, Salesforce said that as of April, Agentforce agents had performed 734 million AWUs, a number growing at about 15% each month.

The research also showed that agents are acting across multiple cloud domains which, the company said, “underscores the practical necessity of a headless architecture. By decoupling the agent’s logic from traditional front-end user interfaces, agents can process tasks, execute actions, and trigger workflows anywhere.”

Within the company, Salesforce itself has seen explosive growth in AI agent use, said Joe Inzerillo, president of enterprise & AI technology at Salesforce, with a threefold increase in sessions between February 2025 and April 2026. He said that the AI agent in Slack, Slackbot, saves the average employee five hours per week, with 83% of the company having adopted it.

But Schwartz pointed out that different industries are approaching agentic AI in different ways, some more sophisticated than others. To measure that, Salesforce developed a Sophistication Index, a five-point scale scoring the cognitive complexity of an agent’s actions. Levels 1- 3  are assigned to tasks such as record lookups, drafting emails, or summarizing documents, while levels 4 and 5 include more complex functions such as updating database fields.

The data showed that manufacturing, financial services, and healthcare and life sciences have built more sophisticated agent networks than what it called traditional AI frontrunners such as technology and retail.

However, Inzerillo said, the most common use case industry wide, and the best place to start, is the service use case, which provides “far and away the best ROI to start with.”

He also noted that, as people have become more conscious of what agents can do, they are asking agents to perform tasks, rather than simply answer questions.

“Now what you’re starting to see people do is very action oriented. So instead of asking ’how do I file a form to request my vacation’ from our employee agent, they’re telling the employee agent, ‘hey I’m taking a vacation, you need to enter this form for me, and here’s the details,’” he said, adding that this bias towards action represents the evolution of agentic use.

A Canadian hacker has admitted being part of a group responsible for several major cyberattacks. Connor Riley Moucka pleaded guilty to being part of a coterie of hackers that hit 165 organizations, resulting in the theft of customer records and the extortion of millions of dollars.

Industry sources have identified Moucka as one of the main players in attacks on data hosted by cloud data warehouse Snowflake. Companies affected by the hacks include the likes of AT&T, Ticketmaster and the Neiman Marcus Group.

He worked with two other hackers: John Edward Binns and Cameron John Wagenius. Binns was not in US custody as of April 2026, while Wagenius, going by the name of Kiberphant0m, was arrested in January 2025 and pleaded guilty in July that year

Moucka and other members of the group used stolen login credentials to compromise data belonging to at least 165 customers of a US-based software-as-a-service company. This unauthorized access was used to steal billions of sensitive customer records and download terabytes of information,

“Connor Moucka hacked over 150 companies and organizations, obtained extremely sensitive information, and extorted the victims for millions of dollars. Today’s guilty plea serves as a reminder to all cybercriminals, regardless of where they live, that they cannot hide behind a wall of anonymity. You will be found and brought to justice,” said assistant attorney general A. Tysen Duva of the Justice Department’s Criminal Division

The trial is the result of a coordinated worldwide action against the Snowflake group. The investigation was led by the FBI but benefited from contributions from the Royal Canadian Mounted Police, the Australian Federal Police, Spain’s Guardia Civil, the Security Service of Ukraine and the Turkish National Police.

This article first appeared on CSO.

There’s something very attractive about saying “we embed very closely with our customers and just figure it out with them”, especially since the company that started “forward deploying engineers” is growing 84% with $5B+ revenue. But “forward deployed engineer” is a vague term and means different things depending on the business you’re running.

I spent almost 5 years at Palantir as a forward-deployed software engineer, and Palantir’s version of an “FDE” does not make sense for most companies I now meet as an early-stage VC. Depending on the type of business you’re building, this role could broadly mean one of two things: “the product builder” or “the platform operator.” Clearly defining which bucket you fall into will make it easier to hire for this role and run your FDE org.

Kabir Sial

The product builder: The OG Palantir version

The north star is: do whatever it takes to actually solve the user’s problem. FDEs are not just responsible for making the platform work, but also discovering what to build and building it (actually creating software) in service of the customer.

The platform operator: Solutions + technical customer success

The north star is: make the product work for the customer – deploy and operationalize it. This is what most startups today really mean when they want FDEs. FDEs here configure the core platform, manage account relationships and drive adoption. This is not new – companies have always had solutions engineers, sales engineers, customer success etc., although the work looks different as FDEs are increasingly building prototypes, configuring evals and building MCPs.

Which FDE is right for you

Kabir Sial

For most situations, hiring product builder FDEs is a mistake.

At scale, the FDEs should be the platform operator. It’s hard to have FDEs build and maintain highly custom product features, especially as the company scales. Over time, the custom product surface area distracts from building the core product, even though AI coding tools make it easy to ship new features quickly and maintain them.

Many fast-growing AI startups recognize these constraints and structure the FDE role more like the platform operator. This also allows them to have 5-10 accounts per FDE, which is a much higher ratio than Palantir had (at least in 2023). Even the Palantir FDE role has evolved to look more like the platform operator.

There are, however, situations when your FDEs should be the product builder archetype.

1. You have very large customers (F500 scale)

Technical complexity: Large customers have complex environments with legacy infrastructure that often requires “out-of-platform” engineering work. I often encountered bespoke data infrastructure, privacy requirements, etc. at various Palantir customers that required me to build “out-of-platform” connectors, UIs and backends.

Organizational inertia and trust: Serving large enterprises is about building trust. In short time periods, overfitting product to a specific user/workflow is often what delivers the most value, builds trust and helps organizations get over the inertia of moving away from Excel and legacy software tools that are part of their day-to-day workflow. For AI-native startups, it’s arguably even more important to invest in doing “unscalable” development with engineering boots on the ground, as it helps solidify your right to exist and eventually expand the customer relationship.

2. You have many ICPs and workflows

If you have a broad range of ICPs and workflows that you serve, your product probably is not walk-up usable on day 1 of deployment. The short-term hacky things that product builder FDEs build to make the product work for these heterogeneous users/workflows will help you shape the product long-term.

Kabir Sial

Note: see Palantir Foundry’s architecture here.

This was a big reason why Palantir FDEs were more like product builders (and are still able to – see the Forward Deployed Software Engineer job profiles as an example). The vision for Foundry was to be the operating system for an enterprise’s critical decisions – inherently multiple industries, users and workflows. A lot of FDE-led development showed that solving many of these use cases required complex data integrations, which led to the early versions of Foundry being best-suited for complex data integrations and building a customer’s “Ontology”. Similarly, FDEs like myself built custom frontend applications for fraud analysis, pricing, etc. As certain patterns of what these applications required became more clear, they were centralized into an application-layer product.

Who you should hire

Kabir Sial

Kabir Sial

Platform operator: There is a much broader set of people you could hire, testing for technical fluency (e.g., being good at data analysis, complex Excel work, even SQL), product intuition and an inclination to build customer relationships. Backgrounds like technical customer success, solutions engineering, software engineering, product management and consulting are all strong fits.

Product builder: You want candidates that are high ownership and missionary software engineers, or technical PMs who want to ship products themselves.

Hiring for these profiles, especially product builders, is hard. It’s worth calling out two things that helped Palantir hire software engineers into what might be considered a less sexy role.

1. Culture of building at the edge: Strong engineers are motivated to build things. Palantir gave FDEs a lot of ownership to build products, which is why much of the core product leadership was former FDEs.
2. Cult built around mission: Internally, there was a cult-like devotion to the mission. Everyone always talked about why outcomes were far more important than software, and why most companies building tools had it wrong. I’ve never been at a company where people feel so closely bonded around a mission.

As founders building AI startups think about hiring FDEs, it’s worth being specific about your culture and asking: Am I just hiring people to support development teams, or am I hiring people to shape and build product? It’s hard to get software engineers (even today) to be excited about an FDE role that might just be technical customer success.

What FDEs should be doing (regardless of archetype)

You’ve hired the right people. How do you best leverage your team of FDEs?

FDEs were Palantir’s way of delivering outcomes rather than tools. AI-native startups can take this much further and FDEs can help in a few unique ways by leveraging their proximity to customers.

1. Find the most critical workflows: As AI lowers the cost of producing software, companies will face a lot more competition. FDEs at AI startups should be constantly finding ways to serve the most critical workflows for a customer and paying attention to how customers do work across newer and legacy tools. For example, FDEs at Harvey should pay attention to which workflows are in Westlaw, which ones are moving to ChatGPT/Claude, and how the Harvey product can stay ahead.
2. Build around nondeterminism: In more regulated environments, FDEs should be hyper-focused on making products reliable for specific use cases using evals and configs. Previously, product reliability lived with product and support. As companies provide outcomes instead of tools, configuring products appropriately and managing evals shifts towards FDE teams.

As enterprises look for ways to cut the cost of running AI models in production, AMD is betting that not every AI workload will be best served by a power-hungry general-purpose GPU.

AMD has agreed to buy Taalas, the Canadian designer of chips that permanently embed a trained AI model’s weights into custom silicon, instead of repeatedly loading them from memory during inference as conventional GPUs do.

Taalas says its approach reduces the time and power required to move model weights between memory and compute units, making things run faster and cheaper.

The result is a highly specialized inference processor optimized for one model, trading the flexibility of programmable hardware for substantially higher throughput and energy efficiency.

Operational tradeoffs

While AMD is planning to integrate the chips into its Instinct GPU roadmap, targeting system-level AI inference solutions in data centers, analysts remain skeptical that enterprises will readily embrace hardware tied to a specific AI model.

Enterprises would, effectively, be buying a chip and a model together because unlike GPUs, which can be repurposed to run different AI models through software updates, Taalas’ chips are tied to a specific trained model, meaning they would need different hardware to support different inference tasks, said Amit Kumar Jena, AI development manager at IT Consulting firm Kanerika.

Or as Forrester Principal Analyst Charlie Dai put it, “The biggest risk is inflexibility.”

The requirement to swap hardware in order to swap tasks would, Dai said, introduce new challenges with costs, governance, capacity planning, lifecycle management, and supplier dependency, especially for enterprises managing multiple AI workloads.

Manoj Chandra Jha, principal analyst at Nord-IQ Research, said the risk of fusing chip and model into one component is larger than one might think, as “early model obsolescence strands both together, so this should be modeled as one shorter-lived asset rather than two independently amortized ones.”

Taalas says it can update a model by modifying only two metal layers of the chip rather than redesigning it from scratch, but that will only apply to chips that haven’t yet left its factory, not those already in use.

That means enterprises will still need to plan for hardware refresh cycles measured in weeks or months and retain programmable GPUs for workloads that evolve frequently, said Pareekh Jain, principal analyst at Pareekh Consulting.

It also means, said Jha, that what is typically a software decision becomes one about capital expenditure for Taalas customers, as replacing or switching workloads or models could require investing in new hardware rather than simply updating software.

Where model-specific silicon fits

Those tradeoffs significantly narrow the range of enterprise workloads where model-specific silicon is likely to make economic sense.

Dai sees the technology as best suited for mature, predictable inference workloads that run at massive scale and rely on relatively stable AI models, such as customer service automation, fraud detection, industrial computer vision, network operations, edge AI, and embedded copilots.

For CIOs, that effectively limits model-specific silicon to a small subset of enterprise AI deployments, rather than a wholesale replacement for GPU infrastructure, he said. “GPUs will remain the preferred enterprise platform because most enterprises value flexibility, multi-tenancy, and rapid model evolution over maximum efficiency.”

This article first appeared on Network World.

Business application development is entering a new operating model. The traditional approach of gathering requirements, designing screens, writing services, integrating systems, testing, fixing defects and preparing release documentation still exists, but it is no longer sufficient for enterprises that need speed, traceability, resilience and regulatory confidence at the same time. Hyperautomation brings a broader discipline to this challenge. It combines workflow orchestration, intelligent document processing, robotic automation, API-led integration, process mining, test automation, observability and artificial intelligence into a connected delivery fabric. With embedded Generative AI, this fabric becomes more adaptive because applications can interpret natural language, summarize complex data, generate explanations, detect exceptions and support decision workflows rather than merely execute predefined rules.

In banking, this shift is especially meaningful. Banks operate across dense application landscapes: trade reporting platforms, wealth management portals, core banking systems, investment banking applications, digital compliance engines, reconciliation utilities, operational dashboards, audit repositories and daily, weekly and monthly reporting platforms. Each of these areas has its own data models, control points, integration patterns, validation rules, exception paths and regulatory obligations. Hyperautomation does not replace engineering discipline; it strengthens it by making business intent, technical execution, control evidence and continuous improvement part of the same lifecycle.

From automation to hyperautomation in banking applications

Automation usually addresses a specific task: moving data from one system to another, generating a report, running a batch job or validating a transaction against a rule. Hyperautomation goes further. It looks at the complete business outcome and asks how the entire chain can be streamlined, governed, observed and improved. For example, a trade reporting process may begin with transaction capture, enrich the trade with reference data, validate regulatory fields, identify breaks, generate a submission file, transmit it to a regulator or trade repository, monitor acknowledgements and preserve audit evidence. A narrow automation script may accelerate one step, but a hyperautomated design coordinates the complete flow, including exception handling and evidence generation.

Magesh Kasthuri

Figure: Automation vs. hyperautomation

Embedded Generative AI adds a new layer of intelligence. Instead of forcing every user interaction into rigid screens and codes, business applications can accept natural language prompts, interpret document content, summarize cases, generate draft responses, explain anomalies, produce test scenarios and create release notes. In a banking environment, this intelligence must be carefully bounded. Every AI-assisted action should be traceable, explainable, reviewable and aligned with data privacy, model risk, information security and regulatory expectations. The goal is not uncontrolled autonomy; the goal is governed acceleration.

Banking application components suitable for hyperautomation

A modern banking application is rarely a single monolithic system. It is a composition of business capabilities, integration services, workflow engines, data pipelines, user experience layers, analytics models, control dashboards and audit stores. Hyperautomation can accelerate the development and integration of these components by turning repetitive engineering work into reusable patterns and by embedding intelligence directly into business processes.

• Trade reporting applications: Generative AI can help map trade attributes to regulatory fields, explain validation failures, summarize rejected submissions and generate test cases for reporting scenarios. Hyperautomation can orchestrate enrichment, validation, submission, acknowledgement tracking and evidence archival.
• Wealth management platforms: Advisors can use embedded AI to summarize client portfolios, generate suitability narratives, identify missing documents and prepare personalized investment review notes. Automation can coordinate onboarding, risk profiling, document verification, portfolio rebalancing workflows and client communication approvals.
• Core banking applications: Account opening, loan servicing, deposits, payments, interest calculations and customer maintenance can benefit from automated validations, intelligent forms, workflow routing and natural language assistance for operations teams. AI can explain account events or transaction exceptions in plain language.
• Investment banking systems: Deal pipelines, research workflows, underwriting processes, trade lifecycle functions and risk calculations require strong coordination across front-office, middle-office and back-office platforms. Hyperautomation can standardize approvals, documentation, exception resolution and control evidence across these stages.
• Digital compliance applications: Compliance teams can use AI to summarize policy obligations, compare regulatory changes with internal controls, classify alerts, draft investigation notes and produce evidence packs. Automation ensures routing, approvals, segregation of duties, audit trails and regulatory reporting timelines are consistently enforced.
• Reconciliation platforms: AI can assist in matching narratives, explaining breaks, clustering exception patterns and suggesting resolution actions. Hyperautomation can pull data from ledgers, statements, payment processors, trading systems and data warehouses, then route unresolved breaks to the right teams.
• Reporting and audit applications: Daily, weekly and monthly reports can be generated through controlled data pipelines, automated quality checks, narrative generation, variance explanations and approval workflows. Audit applications can preserve lineage, approvals, source extracts, model outputs and control attestations.

Embedded generative AI as an application capability

Embedding Generative AI into business applications should be treated as an architectural capability, not as a decorative chatbot. A banking application may use AI for search, summarization, reasoning support, content generation, code generation, policy interpretation or anomaly explanation. Each use case requires clear boundaries. The application must know which data the model can access, which actions require approval, what evidence must be captured and where deterministic controls must override probabilistic suggestions.

For example, in trade reporting, an embedded AI assistant can explain why a transaction failed validation and suggest likely fields to review. However, the final correction should pass through rule-based validations, maker-checker approval and audit logging. In wealth management, AI may draft a client review note based on portfolio movements and risk profile, but the advisor must verify suitability, disclosures and final communication. In reconciliation, AI can propose likely matches or categorize break reasons, while the system preserves the original data, confidence score, reviewer action and final resolution path.

Hyperautomating the product development lifecycle

The Product Development Lifecycle can itself become hyperautomated. Instead of treating ideation, analysis, design, development, testing, security review, release and operations as disconnected phases, enterprises can create an AI-assisted delivery loop where every stage produces structured artifacts that the next stage can consume. Platforms such as GitHub Copilot, Claude Code or Claude Cowork-style agentic development environments and OpenAI Codex can support this movement by helping teams reason over requirements, generate code, create tests, review changes, modernize legacy modules and produce documentation. Their value increases when they are connected to repositories, issue trackers, design documents, build pipelines, test suites, security scanners, observability data and enterprise knowledge bases.

Role of GitHub Copilot, Claude Cowork and Codex

GitHub Copilot is useful where developers need assistance inside the engineering flow: explaining code, generating functions, proposing tests, reviewing pull requests and helping teams move from issue to implementation. In a banking PDLC, it can accelerate microservice creation, API integration, batch processing logic, reconciliation rules, regulatory validation routines and UI workflows. When used with repository context and proper review discipline, it can reduce the time developers spend on repetitive coding while preserving human accountability for design and correctness.

Claude Cowork or Claude Code-style agentic environments are valuable for multi-file reasoning, refactoring, debugging and documentation-heavy engineering work. Banking applications often contain deep domain logic scattered across services, configuration files, stored procedures, integration scripts and test suites. An agentic coding assistant that can understand a wider codebase context can help engineers analyze dependencies, prepare modernization plans, update multiple files coherently and draft explanations for reviewers. This is particularly useful in core banking modernization, trade reporting rule updates and compliance workflow refactoring.

OpenAI Codex can support issue-to-pull-request workflows, test generation, code review, bug reproduction, migration activities and broader software engineering tasks across the lifecycle. In a hyperautomated PDLC, Codex-like agents can be assigned well-scoped work items, asked to inspect failing tests, propose fixes, create regression coverage and summarize the change for human reviewers. The important design principle is to keep agents inside controlled boundaries: clear prompts, repository permissions, test gates, approval workflows and traceable outputs.

Integration architecture for hyperautomated banking applications

A practical architecture begins with business capability decomposition. Each banking domain should be expressed as a set of bounded capabilities such as customer onboarding, account maintenance, trade enrichment, exception management, portfolio review, control attestation, report generation and audit retrieval. These capabilities should be exposed through APIs, events, workflow tasks, data products and user interfaces. Hyperautomation then connects these capabilities using orchestration engines, event streams, rules engines, AI services, RPA connectors where legacy integration is unavoidable and observability layers that capture business and technical telemetry.

The embedded AI layer should sit behind a secure application service boundary. It should use retrieval-augmented generation where approved policies, product rules, application documentation and regulatory mappings are retrieved from trusted sources. It should avoid uncontrolled exposure of sensitive customer information. Prompt templates, response validation, redaction, grounding checks, model monitoring and human-in-the-loop approval should be part of the production design. In banking, the most successful AI pattern is often not full automation but assisted decisioning with strong controls.

Example: Hyperautomated reconciliation and reporting flow

Consider a reconciliation application that compares ledger balances, payment files, trade settlement records and external statements. In a conventional model, operations teams spend significant time downloading files, running macros, investigating mismatches, documenting break reasons and preparing status reports. In a hyperautomated model, data ingestion is scheduled and monitored, schema checks run automatically, matching engines classify obvious matches, AI assists with ambiguous narratives, exceptions are routed through workflow queues and dashboards update in near real time. At the end of the day, the system can generate a draft operations report explaining unresolved breaks, aging trends, risk exposure and pending approvals.

The same pattern can extend to daily, weekly and monthly reporting. Data quality rules validate inputs, report templates are populated automatically, AI generates narrative commentary on variances, reviewers approve or amend explanations and the final report is archived with lineage and approvals. Audit teams can later retrieve not only the report but also the source extracts, transformation logs, exception history, reviewer decisions and AI-generated drafts. This creates a richer control environment than manual reporting because evidence is captured by design rather than reconstructed later.

Governance, risk and control considerations

Hyperautomation in banking must be designed with governance from the beginning. The development team should define which activities can be automated, which can be AI-assisted and which must remain under human approval. Source code generated by AI must pass normal engineering controls, including peer review, static analysis, dependency scanning, secure coding checks, test execution and production readiness review. Business outputs generated by AI, such as compliance narratives or client-facing explanations, should be reviewed where regulatory or reputational risk is material.

Data governance is equally important. AI-enabled applications must respect data classification, residency, retention, masking and access policies. The model should not become an uncontrolled channel through which confidential customer, trading or employee information can leak. Every prompt, retrieved source, generated response, user action and final decision may need to be logged depending on the use case. For audit applications, this traceability is not optional; it is the foundation of trust.

Operating model for AI-native PDLC

A hyperautomated PDLC requires changes in team behavior. Product owners should write requirements in a structured manner so that AI tools can generate better stories, acceptance criteria and test scenarios. Architects should maintain living decision records, reference patterns and integration standards that AI agents can use as context. Developers should learn prompt discipline, context packaging and review techniques. Test engineers should focus on coverage strategy, synthetic data, compliance scenarios and defect prevention rather than only manual execution. Operations teams should feed incident learnings back into the backlog so the system improves continuously.

The role of human experts becomes more important, not less. AI can draft, generate, compare and suggest, but domain judgment remains essential. A trade reporting specialist understands regulatory nuance. A wealth advisor understands client suitability. A core banking architect understands transaction integrity. A compliance officer understands control interpretation. Hyperautomation works best when it amplifies these experts and removes repetitive friction around them.

Conclusion

Hyperautomation in business application development is not simply a faster way to write software. It is a new way to connect business intent, engineering execution, operational control and continuous learning. In banking, where applications must be reliable, explainable, secure and compliant, the combination of embedded Generative AI and disciplined automation can transform how applications are designed, built, integrated, tested, released and operated. Trade reporting, wealth management, core banking, investment banking, compliance, reconciliation, reporting and audit functions can all benefit when AI is embedded responsibly and automation is orchestrated across the complete lifecycle.

Platforms such as GitHub Copilot, Claude Cowork or Claude Code and OpenAI Codex can play an important role in this transformation by accelerating analysis, development, testing, review, modernization and documentation. Their greatest value appears when enterprises treat them not as isolated productivity tools but as part of a governed, AI-native PDLC. The future of banking application development will belong to teams that can combine human expertise, reusable engineering patterns, intelligent automation and strong governance into one coherent delivery model.

This article was made possible by our partnership with the IASA Chief Architect Forum. The CAF’s purpose is to test, challenge and support the art and science of Business Technology Architecture and its evolution over time as well as grow the influence and leadership of chief architects both inside and outside the profession. The CAF is a leadership community of the IASA, the leading non-profit professional association for business technology architects.

As an aviation industry veteran with over 30 years of experience, Alaska Airlines CIO Charu Jain is all too familiar with the technology integration process that often follows a big airline merger.

By her count, she’s been involved in four such projects. But none, she says, has brought her greater satisfaction than leading the overhaul of Alaska’s PSS following its $1.9 billion acquisition of Hawaiian Airlines in September 2024.

“This is one of the biggest milestones in any merger work done between airlines,” says Jain, speaking from her company’s Seattle offices just two months after Alaska and Hawaiian completed their transition to a shared PSS.

In its simplest terms, a PSS is an all-encompassing software suite used by airlines to record and manage a passenger’s journey, from booking tickets and checking in baggage at the airport, to boarding the aircraft and accessing the in-flight menu. “A PSS touches almost every function of an airline from employees to guests,” says Jain.

Two brands, one system

At the time of the merger, Alaska and Hawaiian each had its own PSS. No sooner had the ink dried on the deal than the cutover project got underway to bring both airlines’ systems under a single operating platform.

According to Jain, the two airlines agreed from the get-go that they’d retain their own unique historic brands, both with a combined history of close to 200 years, which would be reflected through the system.

“It had never been done before, developing capabilities to enable two brands on one platform,” adds Jain, who also serves as Alaska’s SVP of merchandising and innovation. “We didn’t want a situation where a passenger travelling from Spokane to Seattle on an Alaska-branded flight, and then onto Honolulu on a Hawaiian-branded flight, would have to navigate two separate systems. So we thought about how to make that experience more seamless.”

After settling on a PSS, developed by travel software manufacturer Sabre, Jain and her colleagues began work on migrating the airlines’ millions of bookings and passenger information, while also updating their various guest- and employee-facing tools for the new system.

Selling cutovers and mock flights

Executing a system cutover on such a large scale is a delicate balancing act, not least in a live-environment where, for a major airline, any form of disruption to the passenger experience can be bad for business. So there was no attempt to rush the project.

“To make sure we didn’t have any issues with customers’ bookings, we really took a risk-optimized approach with a phased deployment and a phased cutover,” says Jain.

Much of this hinged on what Alaska refers to as a selling cutover. Starting in October last year, all new bookings were made on the new PSS, which allowed the group to drain old bookings from the legacy system, and start selling tickets six months in advance of the official transition date; the average booking curve for an airline is around six months.

“There was no migration of millions of records and bookings,” says Jain. “This meant when our customers checked in on the first day [of the PSS], it was as if the booking had been made on the native system.”

While this was going on, however, Alaska was hit by a sizeable IT outage that grounded flights across the country and impacted the travel plans of nearly 50,000 passengers. It followed a previous IT outage in July. However, Jain says the disruptions didn’t impact the project in any way.

So in the final months leading up to the cutover completion, Alaska carried out several dress rehearsals to test the system, including mock flights for domestic and international routes in anticipation of the recent launch of several non-stop services to Europe.

This involved real guests arriving at the airport, completing check-in, going through security, and taking their seats as if they were about to take off. Leaving no stone unturned, the simulation also accounted for baggage collection, pets, wheelchair users, and onboard hospitality, stopping just short of passengers being served actual food.

Alaksa completed five such mock rehearsals in all. “The fifth one was when everything worked without any medium or high issues, and gave us the confidence we were ready,” says Jain.

As part of the airline’s scenario planning, it also set up command centers in various locations, including Honolulu and Seattle, to plan for unforeseen and unrelated problems on the day of the cutover.

A dedication to collaboration

A project is only ever as a good as its people, and Jain is quick to hail the collaborative spirit that Alaska and Hawaiian brought to the table. As a PSS involves both the operational side of an airline’s business — touching on everyone from pilots, flight attendants, and baggage handlers — and commercial departments responsible for policies and pricing, this was more than a purely technological undertaking.

“This was about people coming together from two companies to make this one big thing happen,” says Jain.

When Alaska started making bookings on the new PSS last fall as part of the selling cutover, it also began training employees how to use system. It was around that time as well, says Jain, that the airline was confident the transition would be completed by April 2026, just in time for the busy summer travel season.

Since the PSS has been up and running, the company has also introduced a single mobile app to replace Alaska and Hawaiian’s separate existing ones, allowing passengers to personalize their experience to the airline brand they’re more familiar with.

“It’s a much more seamless experience now that there’s no confusion knowing which app to go on, or why they have two booking numbers,” says Jain. Alaska’s employees are also just as happy with their new tools, she adds.

For years, applicant tracking systems and recruiting platforms were treated as HR technology: Important for workflow, efficiency, compliance and candidate experience, but rarely viewed as core security infrastructure. That assumption no longer holds. Once AI begins reading resumes, scoring candidates, conducting interviews, ranking applicants and influencing who moves forward, the hiring platform stops being a passive system of record. It becomes a decision system.

And any system that accepts public input, processes sensitive data and influences business decisions belongs inside the security conversation.

I learned this during an AI hiring platform rollout that never made it to production. The vendor was established, the product had a strong market reputation and the AI feature looked attractive: Upload a resume, compare it to a job description and return a neat percentage match. For recruiters, it promised speed. For executives, it promised modernization.

Before moving real candidate data into the system, I tested it with synthetic resumes. One weak resume came back with a surprisingly strong match. The reason was not hidden in the candidate’s experience. It was hidden in the text. The resume contained language instructing the AI to treat the candidate as an excellent fit, and the system appeared to follow that instruction instead of evaluating the resume on merit.

That changed the question from “Does the tool improve productivity?” to “Can the person being evaluated influence the evaluation itself?”

That is a security question.

The trust boundary has moved

CIOs do not need to become recruiting experts. They only need to look at the mechanics.

An anonymous user submits content into an enterprise system. That content is processed by software. The software then produces an output that can influence a business decision. In every other environment, security teams know what to call that: untrusted input crossing a trust boundary.

The difference is that in hiring, the input looks harmless. It is a resume, a cover letter, a chatbot reply or a spoken answer in an AI-led interview. But once AI reads that content and treats it as instruction, the harmless-looking input becomes part of the system’s control surface.

That is why prompt injection matters in hiring. It is not just an AI oddity or a model behavior issue. It is the same category of failure enterprises have spent decades trying to prevent: User-controlled input changing what the system does. OWASP lists prompt injection as the first risk in its Top 10 for LLM applications, describing it as a case where user prompts alter a model’s behavior or output in unintended ways.

In hiring, the implication is direct: A candidate may be able to manipulate the score, ranking or interview assessment that determines whether a human ever sees them.

The business impact is not theoretical

The obvious risk is that an unqualified candidate moves forward. But the impact is broader.

First, decision quality degrades. Hiring teams adopt AI scoring because they believe it improves signal. If the score can be manipulated, the business is not gaining signal; it is gaining false confidence. Recruiters may spend time on candidates who gamed the system while stronger candidates are buried lower in the queue. A tool bought to reduce friction can quietly create more of it.

Second, cost increases under the appearance of efficiency. Every false positive consumes recruiter time, hiring-manager attention, interview slots and opportunity cost. A small weakness in screening integrity can become a measurable operational drag across open roles.

Third, trust suffers. Candidates already question whether AI hiring tools are fair, explainable or accurate. If it becomes clear that a screening system can be manipulated by hidden instructions or verbal prompting, the issue is no longer just security. It becomes reputational. Strong candidates may lose confidence in the process, and employers may have to defend decisions made by systems they did not fully understand.

Fourth, sensitive data exposure becomes harder to contain. Recruiting systems hold names, addresses, work histories, education histories, compensation details, work authorization information and sometimes accommodation or demographic data. NIST guidance on personally identifiable information includes employment information as linkable personal data that must be protected from inappropriate access, use and disclosure. Yet hiring platforms often receive less security scrutiny than systems holding customer or financial data.

That mismatch is dangerous: High-value data, public-facing workflows and increasing automation.

The 2025 McHire incident should have made this impossible to ignore. Researchers reported that weaknesses in McDonald’s AI hiring platform, including default credentials and an access-control flaw, exposed applicant data at large scale before the issue was patched. The lesson for CIOs is not merely that a weak password was used. The lesson is that AI hiring systems can ship with basic, preventable security failures while still being treated as HR tools rather than enterprise risk surfaces.

Vendor reputation does not transfer to every AI feature

One reason this risk slips through is that buyers often trust the platform brand. Mature vendors may have strong security programs, enterprise customers, compliance documentation and procurement-friendly answers.

But AI features can change the architecture of risk.

A platform that was safe as a workflow tool may behave very differently once it adds resume scoring, interview grading, chatbot screening or automated ranking. The new feature may introduce new inputs, new model behavior, new data flows, new third-party dependencies and new decision points. In practical terms, the attack surface has changed.

CIOs should not allow AI features to inherit trust automatically from the legacy platform around them. When a vendor adds AI, the enterprise should reassess the feature as if it were a new product. That does not mean slowing innovation for bureaucracy. It means AI-enabled decision-making carries different failure modes from ordinary workflow automation.

The ownership gap is the real vulnerability

The biggest risk may not be the model. It may be the ownership gap.

Talent acquisition may buy the tool. HR operations may configure it. The vendor may guide implementation. Procurement and legal may approve the contract. But who owns the security of the candidate-facing AI layer?

In many organizations, the honest answer is unclear.

That ambiguity is where risk grows. Recruiting technology sits at the intersection of public input, sensitive data, third-party software, automated decision support and brand trust. That is exactly the kind of environment that needs named security ownership, asset inventory, vendor review, access-control testing, logging and incident-response planning.

If the hiring stack is not in the security inventory, the organization is already making an assumption it may later regret.

What CIOs should require now

The fix is not exotic. It is applying existing security discipline to a surface that has been underestimated.

Treat every candidate submission as untrusted input. Resumes, cover letters, chatbot responses, interview transcripts and spoken answers should be handled as attacker-controllable content. If AI processes it, the system must separate content from instruction.

Reassess vendors when AI features are introduced. A prior security review should not be treated as permanent approval for new AI capabilities. Ask what changed in the architecture, what data the model sees, what actions it can influence and how manipulation attempts are detected.

Ask AI-specific questions before signing. Can candidate-provided content alter scoring? Are hidden instructions filtered or ignored? Is there human review before AI output influences a decision? Can the vendor produce testing evidence for prompt injection, access control and data exposure risks?

Assign ownership. HR can own the process, but security must own the risk model. AI hiring systems should be included in third-party risk management, application security reviews, access governance, monitoring and incident response planning.

Measure business impact, not just AI adoption. The goal is not to say the recruiting function uses AI. The goal is to improve hiring speed, quality, fairness and cost without creating new risk. If the system cannot protect decision integrity, the business case is weaker than it appears.

The hiring platform is now part of the enterprise attack surface

AI has turned the careers page into more than a front door for applicants. It is now a public input channel feeding systems that store sensitive data and influence workforce decisions.

That makes it a CIO concern.

The next failure in AI hiring may not look like a traditional breach at first. It may look like bad rankings, manipulated scores, unexplainable decisions, wasted recruiter time or a candidate process no one trusts. But underneath those symptoms is a familiar security problem: A system trusted input it should have treated as hostile.

Enterprises have hardened payment systems, customer portals, APIs and employee applications around that lesson. Hiring deserves the same treatment.

AI hiring is not just an HR transformation. It is a security boundary. And it is time CIOs treated it like one.

AI’s impact has been felt across nearly every industry, and its rise has already started to alter several roles in tech, including that of the business analyst. While the rise of agentic AI may have some questioning whether AI will replace business analyst jobs entirely, as we’ve seen with most roles impacted by AI, it’s more likely that AI will augment the role and fundamentally change how BA’s conduct daily business.

“As AI takes on more routine tasks, the human side of the role is becoming even more valuable. It’s becoming more of a hybrid role, where employers are often looking for candidates who can combine technical fluency with strong communication and problem-solving skills, along with sound business judgment,” says Megan Slabinski, district president of technology talent solutions at Robert Half.

AI can save business analysts time in the long run, automating many of the tasks that are time consuming and repetitive around data processing, note taking, and documentation. While automation will impact the daily tasks of the role, business analysts will still be necessary for properly interpreting outputs, collaborating across teams, and maintaining compliance and AI workflows.

AI-driven analysis and automated workflows

With AI-driven analysis, BA’s can use machine learning models for pattern detection, determining risk, and for forecasting demand, while natural language processing (NLP) can be used for text-heavy inputs. AI tools can also assist analysts with decision-making by transcribing meetings and automatically identifying any necessary business requirements, constraints, risks, or dependencies that will impact the project.

As a result, the role is undergoing a shift toward spending less time on monotonous, routine tasks, and instead “spending more time connecting the dots and providing strategic context earlier in the process,” says Slabinksi.

“We’re seeing that business analysts today aren’t spending as much time as they were a few years ago on some manual processes. AI is speeding up tasks like documenting requirements, summarizing stakeholder meetings, generating first drafts of user stories, and even helping create SQL queries or reports,” she adds.

AI can also assist business analysts with interviews and workshops for the discovery phase of a project and autonomously identify patterns in the data that might be overlooked or missed by the human eye. These tools can also enable BAs to create living models that can be adjusted and altered with feedback, as opposed to traditional static documents, and allow for an automated review process for data validation. In terms of maintenance and change management, AI can help with predictive recommendations to get ahead of risks, compliance, and future process updates.

That said, an increased reliance on AI tools while require business analysts to validate AI outputs and assure AI-generated content is accurate, relevant, and ultimately aligned with the overall business strategy. Still responsible for explaining the reasons behind business decisions, business analysts will also need to identifying bias and fairness concerns associated with AI use, and ensure decisions aren’t over-automated.

Ultimately, BA’s will see their responsibilities shift to focusing more on data interpretation, governance, and strategy, and identifying the most practical use cases for enterprise AI adoption.

New skills to focus on

Traditionally, business analysts are responsible for gathering the data as well as processing it for analysis. This comes with a lot of drudgery that can be eased by implementing AI tools into the workflow. Tasks such as routine documentation, formatting, and data crunching can be automated, while analysts provide the human context around that data, as well as a critical eye to the final output.

“Business analysts are often in the mix to make sure that data is accurate and that the requirements are in line with expected outcomes. They can also help ensure AI projects include the appropriate level of human oversight, comply with internal policies and industry regulations, and use data responsibly. While they aren’t solely responsible for AI governance, they often play an important role in raising questions about data sources, bias, whether the outputs make sense, and potential business risks early in a project,” says Slabinski.

BAs will need to develop AI literacy skills to better understand how models are trained and designed as well as data reasoning skills to interpret and validate AI outputs. Prompt-framing skills will also become valuable as analysts will need to know how to properly structure inputs for quality outputs. There will also be a growing emphasis on ethical analysis to identify compliance, bias, and overall fairness of algorithms, and qualified candidates will require strong change management skills to help oversee the adoption of AI-driven workflows.

“The skills becoming more important are the ones that help BAs evaluate AI-generated information and translate it into business recommendations. AI literacy is becoming a baseline expectation, and that includes knowing things like how to query the data and support requirements gathering. Critical thinking, communication, and business acumen are all part of that skill set because employers still need people who can explain what the findings mean and why they matter,” says Slabinski.

Bending Spoons has snapped up Airtable to add to its portfolio of software companies, alongside AOL, Evernote, WeTransfer, Brightcove and Vimeo

Airtable made its name as a builder of low/no code database services, aimed particularly at non-technical staff, but is now one of many vendors facing financial difficulties in the face of the SaaS/AIpocalypse. The arrival of AI coding tools, which offer non-technical employees more flexible ways to build business applications, has hit demand for its services.

Bending Spoons bought Airtable in a deal it valued at just $1.285 billion, a far cry from the $11.7 billion Airtable was worth at its peak.

Bending Spoons has built its portfolio by buying once-successful companies like Airtable that have struggled to cope with newer, nimbler competitors or failed to adapt to emerging technologies. Bending Spoons takes these companies, cuts costs and markets them aggressively with the goal of returning them to profitability.

“Airtable is a pioneering brand reshaping how teams organize data and manage critical workflows. We’re committed to investing in Airtable for the long run, and doubling down on its core strength: bringing teams and workflows together in one flexible workspace. We plan to expand what can be done across the full spectrum of work and make Airtable even more valuable to customers at every scale,” said Luca Ferrari, Bending Spoons CEO and co-founder.

This article first appeared on InfoWorld.

Technology leaders are facing a sobering reality: They’re investing heavily in AI, yet many initiatives continue to struggle to move beyond experimentation and pilot programs. For example, Gartner found only 28% of AI use cases in infrastructure and operations fully succeed and meet ROI expectations, while 20% fail outright.

The conversation around AI often focuses on models, tools and technical capabilities. Those decisions matter, but in my experience, they are rarely the only factors that determine success. The organizations realizing meaningful value from AI are also focused on operational readiness, governance, employee adoption and measurable outcomes.

As both CIO and CDO, I spend a lot of time helping our organization navigate AI adoption while balancing the needs of our internal teams, our clients and running 24×7 secure operations. What I have learned is that AI transformation depends on how well the organization understands its data, improves its business processes and prepares people to work differently.

I sometimes describe my role as being the organization’s traffic light. The green lights are easy – these are moments when the right answer is to accelerate. There are also moments when we need to slow down. As leaders, we must assess when we need to focus on the fundamentals and make sure the organization is ready for what comes next. And the most important decisions are the red lights – when we prevent the organization from spending time, money and energy on the wrong things.

AI adoption breaks down when it does not fit how people work

One common misconception about AI transformation is that deployment automatically creates adoption. In practice, adoption happens when employees understand how the technology improves their work and have confidence in how it fits into their day-to-day responsibilities.

I have seen AI pilots work well with small groups of users and then encounter challenges when expanded across larger teams. The technology may perform as expected, but the operating environment changes. Teams follow different workflows. Information is managed differently across functions. Employees have different levels of trust in the data. Success is not always measured the same way.

These are readiness, process and change management issues.

We saw similar lessons during our own transformation work. As part of a broader modernization program, we consolidated more than 50 engineering tools into one software delivery platform supporting thousands of developers. The technical migration mattered, but the bigger effort was helping teams adopt new ways of working and establish common practices.

Anyone who has asked developers to move away from their favorite tools knows that change management is real. That experience reinforced a lesson: Transformation succeeds when people understand the value of the change, have the right support and can see how it improves the work they do every day.

The same principle applies to AI.

When we began introducing AI capabilities internally, we avoided a broad rollout from day one. Rolling AI out to thousands of employees is a process of education, adoption support and continuous learning. We introduced capabilities in phases, helped employees understand use cases relevant to their role and gave teams room to build confidence over time. Different teams adopt AI differently, so we found that cohort-based deployment and tailored change management created better long-term adoption than broad enterprise-wide rollouts.

Pilots often succeed because the variables are limited. Production environments introduce the realities of the enterprise: inconsistent processes, disconnected data, unclear ownership and varying levels of employee readiness. In many cases, issues that surface during scaling can be traced back to operating model decisions, process gaps or unclear expectations.

Employees need to understand where AI fits, when human judgment remains essential and how success will be measured. Without that clarity, scaling becomes much harder.

Creating the operational conditions for AI success

The most successful AI transformations start before AI is introduced.

They begin with understanding where employees experience friction. In most enterprises, those opportunities are not difficult to find. Repetitive administrative work and manual handoffs consume time and slow the business down. Employees directly in the workflows have the clearest view of where these issues exist.

When we launched our own efficiency and transformation program, we deliberately did not start with AI. We started by evaluating our data, reviewing business processes and identifying opportunities to simplify how work was performed. We found that simplifying and standardizing workflows before introducing AI significantly reduced complexity during deployment. Rather than asking AI to compensate for fragmented processes, we focused first on creating a consistent operational foundation. We focused first on process improvement, automation and operational discipline. Once those foundations were in place, we began layering AI into the environment.

AI outcomes are heavily influenced by the quality of the processes and the data along with the governance structures supporting them. If the underlying process is inconsistent, AI will struggle to create consistent value. If the process is understood, governed and measurable, AI has a much stronger foundation.

I often say that good data and good processes deliver good AI outcomes. That continues to hold true regardless of the model or technology being deployed.

The real challenge is making sure employees know what AI is using, where it fits in the workflow and when they should rely on the output. If that is unclear, adoption slows. People may not trust the answer, may use the tool inconsistently or may avoid changing how work gets done.

Before scaling AI, leaders need to answer a few basic questions. What problem are we solving? Is the process consistent enough? Is the data reliable enough? Where does human judgment still matter? And how will we know whether the tool is improving the work? Those questions determine whether AI becomes part of how teams operate.

Measure outcomes before you scale

AI programs often lose momentum when leaders measure activity instead of impact. 63% of high-maturity organizations implement formal metrics to evaluate transformation efforts.

Leaders often track how many employees have access to AI, how many licenses have been provisioned or how many use cases have been launched. Those metrics can be useful, but they do not always show whether the organization is creating business value. Activity is not the same as impact.

The more meaningful indicators are instead tied to operational performance: support ticket volumes, incident reduction, productivity improvements, user experience, cycle times and service quality.

We have seen the value of this approach firsthand. As part of our transformation program, we standardized service delivery processes and moved hundreds of teams onto a common service management platform. In our own experience, process improvements and platform consolidation initially reduced support ticket volumes by approximately 30%.

After that foundation was established, additional automation and AI capabilities helped drive reductions closer to 70%.

The initial improvement came from better processes and greater operational consistency. Automation and AI then helped accelerate the results. That is the pattern leaders should look for: Identify where work slows down, improve the process, establish accountability and introduce AI where the environment is ready to support it.

This approach also helps build trust. Employees can see the value being created. Leaders can measure progress. Teams can learn from early deployments before scaling more broadly.

Preparing people is the real AI strategy

Technology adoption has always been closely connected to people.

Employees are more likely to embrace change when they understand how technology helps them be more effective. They need practical experience, clear expectations and opportunities to learn. AI introduces new ways of working, and organizations need to prepare employees for that shift.

In our own organization, we encouraged every employee to establish an AI-related learning goal because familiarity with emerging technologies is becoming part of every role. Some goals were simple. Some were more advanced. The important point was creating a culture where people continue to learn and understand how AI applies to their work versus forcing AI activity broadly all at once.

As AI becomes more embedded in enterprise operations, organizations with strong foundations in governance, process discipline and workforce readiness will be better positioned to capture long-term value.

The companies realizing the greatest value from AI are investing in technology while also strengthening the operating models, information management practices and employee capabilities that support adoption. Sustainable transformation requires attention to people, processes, data and technology.

Preparing people, building trust and creating clear operating models remain central to any successful AI strategy.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Technology leaders are facing a sobering reality: They’re investing heavily in AI, yet many initiatives continue to struggle to move beyond experimentation and pilot programs. For example, Gartner found only 28% of AI use cases in infrastructure and operations fully succeed and meet ROI expectations, while 20% fail outright.

The conversation around AI often focuses on models, tools and technical capabilities. Those decisions matter, but in my experience, they are rarely the only factors that determine success. The organizations realizing meaningful value from AI are also focused on operational readiness, governance, employee adoption and measurable outcomes.

As both CIO and CDO, I spend a lot of time helping our organization navigate AI adoption while balancing the needs of our internal teams, our clients and running 24×7 secure operations. What I have learned is that AI transformation depends on how well the organization understands its data, improves its business processes and prepares people to work differently.

I sometimes describe my role as being the organization’s traffic light. The green lights are easy – these are moments when the right answer is to accelerate. There are also moments when we need to slow down. As leaders, we must assess when we need to focus on the fundamentals and make sure the organization is ready for what comes next. And the most important decisions are the red lights – when we prevent the organization from spending time, money and energy on the wrong things.

AI adoption breaks down when it does not fit how people work

One common misconception about AI transformation is that deployment automatically creates adoption. In practice, adoption happens when employees understand how the technology improves their work and have confidence in how it fits into their day-to-day responsibilities.

I have seen AI pilots work well with small groups of users and then encounter challenges when expanded across larger teams. The technology may perform as expected, but the operating environment changes. Teams follow different workflows. Information is managed differently across functions. Employees have different levels of trust in the data. Success is not always measured the same way.

These are readiness, process and change management issues.

We saw similar lessons during our own transformation work. As part of a broader modernization program, we consolidated more than 50 engineering tools into one software delivery platform supporting thousands of developers. The technical migration mattered, but the bigger effort was helping teams adopt new ways of working and establish common practices.

Anyone who has asked developers to move away from their favorite tools knows that change management is real. That experience reinforced a lesson: Transformation succeeds when people understand the value of the change, have the right support and can see how it improves the work they do every day.

The same principle applies to AI.

When we began introducing AI capabilities internally, we avoided a broad rollout from day one. Rolling AI out to thousands of employees is a process of education, adoption support and continuous learning. We introduced capabilities in phases, helped employees understand use cases relevant to their role and gave teams room to build confidence over time. Different teams adopt AI differently, so we found that cohort-based deployment and tailored change management created better long-term adoption than broad enterprise-wide rollouts.

Pilots often succeed because the variables are limited. Production environments introduce the realities of the enterprise: inconsistent processes, disconnected data, unclear ownership and varying levels of employee readiness. In many cases, issues that surface during scaling can be traced back to operating model decisions, process gaps or unclear expectations.

Employees need to understand where AI fits, when human judgment remains essential and how success will be measured. Without that clarity, scaling becomes much harder.

Creating the operational conditions for AI success

The most successful AI transformations start before AI is introduced.

They begin with understanding where employees experience friction. In most enterprises, those opportunities are not difficult to find. Repetitive administrative work and manual handoffs consume time and slow the business down. Employees directly in the workflows have the clearest view of where these issues exist.

When we launched our own efficiency and transformation program, we deliberately did not start with AI. We started by evaluating our data, reviewing business processes and identifying opportunities to simplify how work was performed. We found that simplifying and standardizing workflows before introducing AI significantly reduced complexity during deployment. Rather than asking AI to compensate for fragmented processes, we focused first on creating a consistent operational foundation. We focused first on process improvement, automation and operational discipline. Once those foundations were in place, we began layering AI into the environment.

AI outcomes are heavily influenced by the quality of the processes and the data along with the governance structures supporting them. If the underlying process is inconsistent, AI will struggle to create consistent value. If the process is understood, governed and measurable, AI has a much stronger foundation.

I often say that good data and good processes deliver good AI outcomes. That continues to hold true regardless of the model or technology being deployed.

The real challenge is making sure employees know what AI is using, where it fits in the workflow and when they should rely on the output. If that is unclear, adoption slows. People may not trust the answer, may use the tool inconsistently or may avoid changing how work gets done.

Before scaling AI, leaders need to answer a few basic questions. What problem are we solving? Is the process consistent enough? Is the data reliable enough? Where does human judgment still matter? And how will we know whether the tool is improving the work? Those questions determine whether AI becomes part of how teams operate.

Measure outcomes before you scale

AI programs often lose momentum when leaders measure activity instead of impact. 63% of high-maturity organizations implement formal metrics to evaluate transformation efforts.

Leaders often track how many employees have access to AI, how many licenses have been provisioned or how many use cases have been launched. Those metrics can be useful, but they do not always show whether the organization is creating business value. Activity is not the same as impact.

The more meaningful indicators are instead tied to operational performance: support ticket volumes, incident reduction, productivity improvements, user experience, cycle times and service quality.

We have seen the value of this approach firsthand. As part of our transformation program, we standardized service delivery processes and moved hundreds of teams onto a common service management platform. In our own experience, process improvements and platform consolidation initially reduced support ticket volumes by approximately 30%.

After that foundation was established, additional automation and AI capabilities helped drive reductions closer to 70%.

The initial improvement came from better processes and greater operational consistency. Automation and AI then helped accelerate the results. That is the pattern leaders should look for: Identify where work slows down, improve the process, establish accountability and introduce AI where the environment is ready to support it.

This approach also helps build trust. Employees can see the value being created. Leaders can measure progress. Teams can learn from early deployments before scaling more broadly.

Preparing people is the real AI strategy

Technology adoption has always been closely connected to people.

Employees are more likely to embrace change when they understand how technology helps them be more effective. They need practical experience, clear expectations and opportunities to learn. AI introduces new ways of working, and organizations need to prepare employees for that shift.

In our own organization, we encouraged every employee to establish an AI-related learning goal because familiarity with emerging technologies is becoming part of every role. Some goals were simple. Some were more advanced. The important point was creating a culture where people continue to learn and understand how AI applies to their work versus forcing AI activity broadly all at once.

As AI becomes more embedded in enterprise operations, organizations with strong foundations in governance, process discipline and workforce readiness will be better positioned to capture long-term value.

The companies realizing the greatest value from AI are investing in technology while also strengthening the operating models, information management practices and employee capabilities that support adoption. Sustainable transformation requires attention to people, processes, data and technology.

Preparing people, building trust and creating clear operating models remain central to any successful AI strategy.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

• Gute Tischmanieren sind karrierefördernd.
• Ein guter Gastgeber sorgt sich um das Wohl seiner Gäste.
• Zurückhaltende Gäste sollten Sie in Gespräche mit einbinden.

Andere denken sich nichts und merken gar nicht, dass sie bereits mehrfach ins Fettnäpfchen getreten sind, zum Beispiel wenn sie das Brot wie eine Stulle beschmieren und vor dem Hauptgang verzehren. Einige Peinlichkeiten sind offensichtlicher, könnten aber galant gelöst werden. Beherrscht man die Regeln und Sitten bei Tisch, ist es ein Leichtes, konzentriert dem Gespräch des Partners zu folgen und sich ganz und gar auf den Inhalt des Geschäftstermins statt auf die richtige Besteckreihenfolge zu konzentrieren.

Foto: Photographee eu – shutterstock.com

Kleckern

… tun nicht nur kleine Kinder bei Tisch. Schnell ist ein Soßenfleck auf der Tischdecke gelandet. Bleiben Sie enspannt! Jede Serviette und auch die Tischtücher werden nach dem Essen gereinigt und dabei ist ein Fleck mehr oder weniger nicht ausschlaggebend. Lassen Sie also Salzstreuer und Dekoration dort wo sie sind und übersehen Sie souverän Ihren Fleck neben den Teller. Flutscht ein Salatblatt vom Tellerrand auf den Tisch, befördern Sie es wieder auf Ihren Teller. Fällt ein Haps auf den Boden, lassen Sie ihn liegen. Rutscht Ihnen die Serviette auf den Boden, krabblen Sie bitte nicht unter den Tisch. Lassen Sie sich einfach eine neue Serviette geben. Ein guter Service wird Ihnen von selbst eine neue Serviette geben.

Das berühmte Haar in der Suppe

Wird Ihr Essen nicht so geliefert wie Sie es bestellt haben, rufen Sie den Service zu sich und sagen in einem ruhigen Ton, was nicht stimmt. Am Anfang des Essens kann der Service Abhilfe schaffen, fällt das Haar erst am Ende des Essens auf, sollte der Kellner neben der Entschuldigung auch eine Wiedergutmachung parat haben.

Foto: Haufe Lexware

Unaufmerksames Personal

Manch Restaurantbesucher fragt sich, ob es dem Servicepersonal regelrecht beigebracht wird, wie man Kunden ignoriert. Haben Sie als Gast das Gefühl, ständig übersehen zu werden, entschuldigen Sie sich bei Ihren Gästen und gehen Sie zur Bar oder fangen Sie das Personal an ihrer “Station” ab, um Ihre Wünsche loszuwerden. Es ist Ihre Aufgabe als Gastgeber, aktiv Regie zu führen und den Restaurantbesuch so angenehm wie möglich zu gestalten.

Telefonierende Nachbargäste

Laute oder unangenehme Tischnachbarn dürfen gerne auf eine angemessene Gesprächlautstärke hingewiesen werden. Möchten Sie keine direkte Konfrontation mit einem anderen Gast eingehen, können Sie auch den Service bitten, dies für Sie zu übernehmen. Grundsätzlich ist ein Restaurant kein Büro und Telefonate sollten nicht am Tisch geführt werden. Bitten Sie in einem freundlichen Ton darum, dass das Telefonat nach draußen verlegt wird, da es Ihre Unterhaltung stört.

Meine Suppe ess ich nicht….

Wurde das Menü vorher ausgewählt und gibt es eine Speise, die Sie nicht essen möchten, können Sie diese gerne beim Kellner gegen eine andere Speise austauschen. (Also statt der Tomatensuppe eventuell eine klare Brühe.) Einen Gang sich nicht servieren zu lassen, ist keine gute Lösung, da der Gastgeber erst mit dem Essen startet, wenn allen serviert wurde. Die Absprache zwischen Ihnen und dem Kellner hat er dann vielleicht nicht mitbekommen. Essen Sie von der servierten Speise, dass was Sie essen können oder wollen und lassen den Rest zurückgehen. Sie sind nicht verpflichtet, Ihren Teller leer zu essen.

Langweilige Tischpartner

…können einen Abend unendlich lang erscheinen lassen. Wenn der Smalltalk mit Ihrem Tischherrn oder der Tischdame nicht läuft, müssen Sie selber in die Bresche springen und Geschichten und Wissenswertes erzählen. Klassische Smalltalk-Themen sind Urlaube, Freizeit, Hobbies und Wochenendplanungen. Geht Ihr Gesprächspartner auf nichts ein, versuchen Sie auf die Gemeinsamkeiten Ort, Umfeld und Anlass einzugehen. Klappt auch das nicht, können Sie sich eventuell in ein Nachbargespräch mit einklinken und bei Bedarf die Gesprächsführung so leiten, dass der wortkarge Nachbar seine Meinung zu dem ein oder anderen Thema beisteuern kann oder soll. Erst zum Kaffee dürften Sie die Sitzordnung auflösen und sich einen neuen Gesprächspartner suchen.

Mehr Tipps…

…rund um das Verhalten bei einem Geschäftsessen können Sie in dem Haufe TaschenGuide “Geschäftsessen meistern” von Christina Tabernig und Anke Quittschau nachlesen. Außerdem finden Sie Informationen zu Coaching und Seminaren der Autorinnen auf der Webseite www.korrekt.de.

Foto: Christina Tabernig

Mehr zum Thema Knigge…

Mit guten Tischmanieren punkten

Neulich in … einem Münchner Restaurant

Soforthilfe für peinliche Knigge-Blackouts

Dragon Images | shutterstock.com

Als Umgebung für Entwickler hat Microsoft Windows in den letzten Jahren einen Sprung nach vorne gemacht. Mit dem Windows-Subsystem für Linux (WSL) ist es nahtlos möglich, mit Linux unter Windows zu arbeiten – ohne den Mehraufwand, den eine virtuelle Maschine (VM) mit sich bringt. Zudem sind sämtliche gängigen Dev-Tools als native Windows-Versionen verfügbar – und Microsoft hat eine ganze Reihe entsprechender Funktionen auch direkt in sein Betriebssystem integriert.

Für Developer, die besonders schnell mit einer Windows-Maschine entwickeln wollen, hat Microsoft mit der „Windows Developer Config“ sogar so etwas wie eine Schnellspur geschaffen: Diese Sammlung von Powershell-Skripten fungiert als eine Art „Starter Kit“ und unterstützt dabei, Windows-Systeme möglichst schnell und komfortabel als Entwicklungsumgebung einzurichten. 

Wenn Sie hingegen – wie die meisten Entwickler – Wert darauflegen, die Kontrolle zu behalten und Ihr Dev-System selbst einzurichten und zu konfigurieren, ist ein bisschen Vorarbeit nötig. Der Aufwand selbst ist dabei überschaubar, die konkreten Schritte sind jedoch erfolgsentscheidend (und nicht unbedingt offensichtlich).   

Hinweis: Um die nachfolgenden Maßnahmen umzusetzen, sollten Sie auf Ihrem System über Administratorrechte verfügen.

1. WSL installieren

WSL stellt Windows-Benutzern ein vollständiges Linux-System über die Kommandozeile zur Verfügung – was weniger Overhead verursacht als eine VM. Da Software weltweit vor allem unter Linux– oder Unix-ähnlichen Systemen wie macOS entwickelt wird, ist das ein echter Vorteil.

Um WSL zu installieren, öffnen Sie ein Konsolenfenster mit Administratorrechten und nutzen den Befehl:

wsl --install

Die Installation kann einige Zeit in Anspruch nehmen, da das System sowohl die Kernkomponenten für WSL als auch – damit zusammenhängend – eine Linux-Distribution herunterladen muss.

Die Standard-Linux-Distribution in WSL ist Ubuntu 26.04 LTS. Diese erfüllt als Default-Lösung die meisten Anforderungen, die Entwickler an eine Linux-Distribution stellen. Es stehen jedoch auch andere Distributionen zur Verfügung – und es kommen regelmäßig neue hinzu. Sie könnten sogar Ihre eigene, benutzerdefinierte Linux-Distribution für WSL kreieren.

Sobald WSL installiert ist, können Sie über den Befehl wsl –list –online alle verfügbaren Distributionen anzeigen. Um eine davon zu installieren, nutzen Sie den Befehl wsl --install . Die meisten verfügbaren Optionen sind auf unterschiedliche Vorlieben oder spezifische Anforderungen zugeschnitten. Wenn Sie beispielsweise an einem Projekt arbeiten, das Debian als Grundlage voraussetzt, sollten Sie das auch installieren.

WSL-Distributionen werden standardmäßig im AppData-Verzeichnis abgelegt – genauer gesagt unter AppData\Local\Packages\. Wenn Sie die Dateien in ein anderes Verzeichnis oder auf ein anderes Laufwerk verschieben möchten, können Sie das mit dem Befehl wsl --manage --move bewerkstelligen.

Darüber hinaus hat Microsoft Ende Juni 2026 mit WSL-Container (derzeit in der Public Preview) eine wichtige neue Funktion für WSL vorgestellt. Diese ermöglicht es, Linux-Container nativ unter Windows auszuführen.

2. Dev-Drive-Laufwerk konfigurieren

Um Projekte zu speichern, nutzen die meisten Windows-Benutzer standardmäßig ein Verzeichnis auf einem NTFS-Volume – entweder im eigenen Benutzerprofil oder über einen anderen Pfad. Das ist als Default-Option keine schlechte Wahl. Allerdings gibt es bessere Alternativen.

Zum Beispiel „Dev Drive“, ein neuer Laufwerkstyp unter Windows. Dieser nutzt statt NTFS das neuere Dateisystem ReFS („Resilient File System“). Dieses wurde ursprünglich für Windows Server entwickelt und bietet Funktionen, die darauf ausgelegt sind, Softwareentwicklungs-Workloads besser zu bewältigen. Dazu gehören:  

• Copy-on-Write: Projektverzeichnisse können Tausende von Dateien und Dutzende von Unterverzeichnissen enthalten. Kopien von Projekten dieser Art anzufertigen, lässt sich mit ReFS deutlich schneller bewältigen, da das Dateisystem Kopien von Daten erst dann erstellt, wenn diese auch geändert werden. Reine Kopien sind hingegen Links, die auf die Originale verweisen.
• Antivirus-Komfort: Über einen Dev Drive lassen sich die standardmäßigen Beeinträchtigungen durch die nativen Antivirus-Tools von Windows minimieren. Dieses Feature erlaubt es, Entwicklerverzeichnisse manuell von Scan-Vorgängen zu exkludieren.
• Virtuelle Festplatte oder Partition: Dev Drives können als virtuelle Festplattendatei eingerichtet oder direkt auf einer formatierten Partition genutzt werden. Ersteres ist flexibler (unter anderem lässt sich die Größe leichter anpassen), Letzteres möglicherweise performanter.

Zwei Dinge sollten Sie im Zusammenhang mit Dev Drives unbedingt beachten:

1. Dev Drives sind für Projekte gedacht, nicht für Tools: Dort legen Sie Ihre Projekt-Repositories, Build-Artefakte und zwischengespeicherte Dateien ab. Language Runtimes, Compiler oder anderen Toolchain-Utlities sollten hingegen auf regulären NTFS-Volumes gespeichert werden.
2. Low-Level-Tools funktionieren unter Umständen nicht wie beabsichtigt: Dateisystem-Utilities auf Expertenniveau, die Informationen direkt aus den Dateiinformationen auslesen, verhalten sich im Zusammenspiel mit ReFS-Volumes möglicherweise nicht wie vorgesehen. So ist etwa das Speicherplatz-Management-Tool WizTree unter ReFS extrem langsam.

3. WinGet nutzen

Microsoft hat Windows inzwischen auch mit einem offiziellen Package-Management-System ausgestattet – WinGet. Dieses installiert jede Art von Windows-Applikation und bietet zudem ein vollständiges Befehlszeilen-Interface für Interaktion und Automatisierung.    

WinGet wird vom Windows-Software-Ökosystem umfassend unterstützt – die Wahrscheinlichkeit ist also groß, dass es für jedes Windows-Programm, das Sie benötigen, ein WinGet-Paket gibt (dazu gleich mehr).

Um im WinGet-Repository nach einem Paket zu suchen, nutzen Sie diesen Befehl (die Anführungszeichen sind erforderlich, wenn der Name des gesuchten Pakets Leerzeichen enthält – etwa Adobe Acrobat Reader):

winget search "Thing to search for"

Foundry

Das WinGet-Package zu installieren, geht denkbar simpel von der Hand – und zwar mit:

winget install 

Dabei meint die ID des zu installierenden Pakets – nicht bloß seinen Namen. Im vorgenannten Beispiel (Adobe Acrobat Reader) würden Sie also folgenden Befehl nutzen, um dieses zu installieren:

winget install Adobe.Acrobat.Reader.64-bit

Falls Sie eine ansprechende grafische Benutzeroberfläche suchen, empfiehlt sich ein Blick auf UniGetUI. Dieses Tool verwaltet Packages aus verschiedenen Quellen – etwa WinGet, Scoop, Chocolatey, npm, pip oder Cargo, um nur einige zu nennen.

4. PowerShell für Skripte konfigurieren

Dieser Schritt ist lediglich einmal pro System zu absolvieren, kann jedoch die Entwicklererfahrung von Windows gewaltig steigern: PowerShell sollte entsprechend konfiguriert werden, damit lokale Skripte ausgeführt werden können.   

Um das zu bewerkstelligen, starten Sie PowerShell als Admin und nutzen folgendes Kommando:

set-executionpolicy remotesigned

Zwar verlangt Windows weiterhin, dass alle PowerShell-Skripte, die Sie aus dem Internet herunterladen, signiert sind – das ist jedoch im Grunde ein Edge Case. Alle lokal erstellten Skripte funktionieren nach dieser Maßnahme ohne Weiteres.

5. Weitere Dev-Tools installieren

Wie bereits erwähnt, bietet WinGet schnellen Zugriff auf alle gängigen Tools, die ein entwicklungsorientiertes Windows-System benötigt. Nachfolgend haben wir eine kleine Übersicht der wichtigsten Dev-Tools für Windows inklusive deren WinGet-IDs zusammengestellt, um Ihnen die Installation zu erleichtern.

• Git (Git.Git): Die Windows-Version des populären Versionskontrollsystems ist im Wesentlichen identisch mit der auf anderen Plattformen.
• Visual Studio BuildTools 2022 (Microsoft.VisualStudio.2022.BuildTools): Dieses minimale CLI-Tooling ist erforderlich, um das C/C++-Kompilierungssystem von Visual Studio zu nutzen.
• CMake (Kitware.Cmake): Die plattformübergreifende Build-Lösung wird häufig für größere oder komplexere Projekte benötigt, die C/C++ nutzen.

Dabei ist zu beachten, dass die standardmäßige BuildTools-Installation in der Regel nicht über die Tools verfügt, die für minimale C/C++-Build-Prozesse erforderlich sind. Das beheben Sie mit folgendem Befehl:

winget install -e --id Microsoft.VisualStudio.2022.BuildTools --force --override "--passive --wait --add Microsoft.VisualStudio.Workload.VCTools;includeRecommended"

Alle gängigen Editoren sind ebenfalls als native Windows-Apps über WinGet verfügbar – etwa:

• Microsoft Visual Studio Code (Microsoft.VisualStudioCode),
• GNU Emacs (GNU.Emacs), oder
• Neovim (Neovim.Neovim).

Für die Softwareentwicklung unter Windows optional, aber durchaus nützlich, sind außerdem folgende Werkzeuge:

• CoreUtils for Windows (Microsoft.Coreutils): Ein von Microsoft gepflegtes Open-Source-Projekt, das Dutzende von Linux-Befehlszeilen-Dienstprogrammen auf Windows bringt, beispielsweise cp, grep, find und ls.
• MSYS2 (MSYS2.MSYS2): Eine Tool-Sammlung, um Windows-Binärdateien mit dem GCC-Compiler zu erstellen. Diese bildet im Grunde eine Alternative zum Visual-Studio-Build-Stack auf Basis der Cygwin-Umgebung.
• LLVM (LLVM.LLVM): Auf diesem Compiler-Framework basieren Clang, Rust, Swift und viele andere Projekte. Wenn Sie LLVM als Abhängigkeit verwenden, müssen Sie die spezifische Version installieren, die Ihr Projekt erfordert.
• Docker Desktop (XP8CBJ40XLBWKX): Die Windows-native Version der Docker-Desktop-App.
• Microsoft PowerToys (Microsoft.PowerToys): Diese Sammlung besteht aus über 30 Utilities, die es erheblich vereinfachen, Windows anzupassen. Dazu gehören unter anderem ein Hosts-File-Editor, ein Unlocking-Tool für Dateien (praktisch, um festzustellen, welche Prozesse eine bestimmte Datei sperren) sowie ein Werkzeug, um Text zu extrahieren (praktisch, um Text von beliebigen Stellen auszulesen, einschließlich Bildschirmbereichen, die nicht mit dem Cursor markiert werden können).

(fm)

Dieser Artikel ist im Original bei unserer Schwesterpublikation Infoworld.com erschienen.

Traditional operating systems (OS) were built to manage hardware, files, apps, and users on a device, but Cloudflare says the agentic AI era requires a whole new format.

The company this week announced Cloudflare OS, which connects AI agents, enterprise data and context, internal systems, and workflows together in one secure workspace. It is open source and browser-based, sparing companies the need to build all-new infrastructure.

The OS is launching alongside several other new security, identity, spending, and user insight tools that Cloudflare has built for the AI-based workplace.

“Cloudflare OS isn’t a traditional desktop OS,” said Rita Kozlov, VP of product at Cloudflare. “It reimagines the workplace computing environment for AI.”

Open source OS runs in a browser

Cloudflare OS serves as a secure, AI-equipped workspace that is plugged into internal company systems. Available now through Cloudflare’s open source repository, it is accessible directly in a browser, and runs inside an enterprise’s Cloudflare account.

“It is a browser-based workspace that begins with a conversation,” Kozlov explained. Users can ask an agent to research, create slides, spreadsheets, and documents, build full-stack apps, or automate workflows without the need for a terminal. Those outputs are then shareable, but kept in isolated databases with access controls.

Enterprises will soon be able to access the OS directly through Cloudflare or via a “select group” of partners that will build tailored offerings on Cloudflare’s architecture, the company says. Because it is open source, organizational processes, internal system connections, and context aren’t locked into a vendor product or AI model provider. Customers can use whatever models they choose.

Cloudflare OS is built on Cloudflare Workers, Dynamic Workers, Durable Objects, and Access, the company’s zero trust network access (ZTNA) tool that verifies every user and request. Agents start with zero permissions by default and are only granted access to tools required for a specific task. Organizations configure their own Access policies, models, branding, skills, and integrations, Kozlov explained.

Governed connectors known as gatekeepers give admins control over what AI can see, what it can change, and when the system needs human sign-off. They can also control budgets, set rate limits, and delegate tasks to different models.

“Because agents act on people’s behalf and produce work others can access and modify, they require a new security model,” Kozlov said. Thus, Cloudflare OS tracks the resources an agent requires so the right access controls follow its work when it is shared.

Cloudflare initially built the OS for internal use, and employees “across every team” use it daily. Kozlov estimated that, over the last 30 days, internal users have used it to create more than 4,000 apps, automations, and tools. Over that same period, she claimed, the company’s sales team saved an estimated 10,000 hours by automating previously manual tasks like territory planning and proposal creation.

“We open sourced Cloudflare OS so any organization can build ‘Your Company OS,’” Kozlov said. Open source is critical because “you cannot put your company into software you do not own. Organizations need to be able to inspect the platform, customize it, connect their own systems, and make it their own,” she explained.

A more cohesive bundle

Cloudflare deserves credit for packaging Cloudflare OS as an operating system, noted tech analyst Carmi Levy.

“This very much is not Windows, macOS, or Linux, and it isn’t an operating system by its common definition,” he said. “But Cloudflare’s use of this terminology implies familiarity to enterprise IT buyers.”

This makes for an easier discussion as enterprises struggle to understand how to best incorporate AI-related platforms and workflows into infrastructure that wasn’t initially designed for it.

Microsoft has marketed the combination of its Azure, Entra, Fabric, Windows, and Microsoft 365 offerings as an operating system of sorts, but hasn’t pulled all the pieces into a common brand, Levy said. And Google’s Gemini, Workspace, Vertex AI, and Cloud Run are “circling similar territory.”

But, he noted, Cloudflare OS is “more cohesively bundled” and infrastructure-focused, offering a single pane of glass platform for buyers worried about stitching together otherwise disparate AI-aware networking pieces. The company recognizes that AI introduces new architectural realities such as inference and model routing “over and above” traditional OS core competencies.

“While competing offerings generally leave the infrastructure heavy lifting to enterprise decision-makers, Cloudflare is marketing itself as a single-source vendor, which potentially frees IT planners from having to integrate all the AI pieces on their own,” Levy said.

An infrastructure-first, application-agnostic approach means Cloudflare OS can coexist with whatever AI applications already exist in an enterprise, he said. It will “play nice” with OpenAI, Anthropic, Google, Microsoft, Meta, or open source layers, allowing employees to begin working in familiar workflows after sign-in.

“Its open-source architecture also minimizes the potential for vendor lock-in as enterprises gradually figure out how to evolve their stacks to align with new AI-era realities,” Levy said.

Managing identities and budgets for both humans and AI

As AI agents emerge across the enterprise, tracking their use can be challenging, causing problems from both a security and a spend standpoint. Along with Cloudflare OS, the company has launched a way to address this issue with its new Identity-Aware AI Gateway, now in beta.

Also integrated with Access, the offering gives admins visibility into what users (both human and AI) are requesting from AI models. It allows security teams to set up custom domains in front of their gateways and replace shared API keys by integrating with their identity provider, like Okta or Entra, and ZTNA infrastructure, Cloudflare explained.

Every request is tied to Access-verified identities, and enterprises can filter each user’s logs, analytics, and spend. IT teams can track redundancies, limit usage rates, and apply filters that strip out employee names, passwords, and other sensitive data before requests go to outside model providers.

A companion feature, AI Spend, tracks every user’s behavior over time to create a baseline of normal AI usage. When spending deviates from that pattern, the system alerts the IT team.

A new tab, User Insights, tracks cost and identifies over-spend caused by activities such as low cache-hit rates or oversized context windows. The capability scores sessions and compares them against account history using a 95th percentile session cost over the previous 30 days, Cloudflare product managers Ming Lu, Kenny Johnson, and Ayush Kumar explain in a blog post. Anything above 2x an account’s 95th percentile is a “strong candidate for anomalous behavior.”

For instance, one Cloudflare customer had an employee who left a rogue AI session running, generating a $30K bill. “User Insights helped them identify the problem and shut off access before the problem was further exacerbated,” Kozlov said.

Cloudflare is also building prompt classification functionality that sorts requests into categories such as coding or writing. This can help enterprises understand what AI is being used for.

“Once business traffic is separated from everything else, personal use becomes visible,” the project managers explained. “From the outside, someone running a side hustle on company time and someone quietly moving data out through a model look the same. Telling them apart is central to catching insider risk.”

Looking at the bigger picture

Identity-Aware AI Gateway and AI Spend address the visibility problem that has dogged so many recent AI deployments where enterprises failed to monitor usage, Levy noted. Projects “crashed and burned” as users unwittingly blew through token allocations.

These platforms provide single-point visibility into what is being used, how it’s being used, and where the potential lies for raising the productivity bar, he said. They overlay with existing models; in doing so, they enhance security with more precise control over resource allocations, and via automated anonymization protocols that prevent inadvertent sharing of sensitive data.

Ultimately, he said, vendors who free IT from having to independently assemble the pieces of their own AI implementations, and who assist them with answers to AI-specific questions, “will gain advantage over vendors that aren’t looking at the bigger picture.

This article originally appeared on CIO.com.

Vulnerability management isn’t failing because security teams lack visibility. Most organizations already have more findings than they can reasonably address. Yet despite all those findings, many CISOs still struggle to answer a deceptively simple question: Are we actually becoming harder to attack?

That question sits at the center of a growing problem. Security programs have become very good at finding issues, but finding issues and reducing risk are not the same thing. In many organizations, those two concepts have become interchangeable, which is exactly why traditional vulnerability management is beginning to break down.

The underlying assumption behind vulnerability management is straightforward. If you can identify vulnerabilities, prioritize them, and patch them, risk should decrease. That logic worked reasonably well when environments were smaller, infrastructure changed at a slower pace, and vulnerabilities were treated as the primary indicator of risk.

Today’s environments operate differently. Vulnerabilities are rarely encountered in isolation and are often only one component of a broader security problem. The challenge is no longer finding vulnerabilities. The challenge is understanding exposure.

This shift is one reason the Gartner^® Continuous Threat Exposure Management (CTEM) framework has gained traction. At its core, the framework recognizes that understanding risk requires looking beyond individual vulnerabilities and evaluating the broader exposures that attackers can actually exploit.

Why prioritization keeps falling short

The challenge becomes apparent when organizations try to prioritize risk. Traditional vulnerability management evaluates findings individually, often using severity scores as a proxy for risk. Attackers take a different approach. They evaluate how weaknesses connect, what access they provide, and how they can be combined to reach a meaningful objective.

That distinction matters because severity and risk are not the same thing. A critical vulnerability that cannot be reached or exploited may represent very little practical risk. Meanwhile, a lower-severity issue combined with weak credentials, excessive permissions, or a misconfigured identity relationship can create a direct path to sensitive systems and data.

Attackers understand this instinctively. They do not attack vulnerabilities one at a time. They chain weaknesses together, move laterally across environments, escalate privileges, and pursue the path that gets them closest to their objective.

Severity is not risk

One of the biggest reasons vulnerability management efforts struggle today is that severity has become a stand-in for risk. It is easy to understand why. Severity scores provide a standardized way to compare findings, helping teams sort large volumes of vulnerabilities and establish remediation priorities.

A vulnerability only matters if it contributes to an attacker’s ability to achieve an objective, whether that objective is accessing sensitive data, escalating privileges, or moving laterally through an environment. In every case, the question is not, “How severe is this vulnerability?” but rather, “Can this weakness be used as part of a path to something valuable?”

Those are fundamentally different questions. One measures the characteristics of a finding. The other evaluates the opportunity it creates for an attacker. As environments become more interconnected, the gap between those perspectives continues to grow.

Exposure is bigger than vulnerabilities

Visibility tells you what vulnerabilities exist. Exposure tells you how attackers can use them.

That distinction is becoming increasingly important because exposure is broader than a vulnerability. It includes the relationships between weaknesses, identities, permissions, assets, trust relationships, and business systems that create opportunities for attackers.

A vulnerability may contribute to exposure, but it is rarely the entire story. Consider a lower-severity vulnerability that exists on a system with excessive permissions. By itself, neither issue may appear urgent. Together, they may provide a direct path to sensitive data or critical infrastructure.

Now consider an attacker who compromises a low-value system. In a traditional vulnerability management model, the focus remains on the vulnerability that enabled access. In an exposure management model, the focus shifts to what happens next: 

• What can the attacker reach? 
• Which identities can be abused? 
• What permissions can be leveraged? 
• What systems become accessible?

The vulnerability may have enabled the intrusion, but the exposure determines the impact. That is why understanding exposure requires looking beyond individual findings and evaluating how weaknesses interact across the environment.

The same principle applies across cloud environments, identity systems, Active Directory, third-party access, and hybrid environments. Attackers do not compromise organizations because a vulnerability exists. They compromise organizations because multiple conditions create an opportunity to reach something valuable.

That is the definition of exposure.

Why exposure management is replacing vulnerability management

Attackers have already made this shift. The industry is finally catching up.

Vulnerability management helped organizations understand what was broken. Exposure management helps organizations understand what attackers can actually do.

As environments become more interconnected, the goal is no longer to identify every vulnerability. The goal is to understand which combinations of weaknesses create meaningful risk and where action will reduce that risk most effectively.

For CISOs, that changes the conversation.

Instead of asking:

• How many vulnerabilities do we have?
• How quickly are we patching them?

The more important questions become:

• What can an attacker actually reach?
• Which exposures create meaningful business risk?
• What should we fix first?
• Are we becoming harder to attack?

Those are exposure management questions. And as attackers gain new ways to identify and exploit opportunities at machine speed, they are increasingly the questions that matter most.

Explore how organizations are operationalizing exposure management through CTEM by downloading the “Operationalizing CTEM: A Practical Playbook for Continuous Threat Exposure Management.” You’ll learn how leading teams are moving beyond visibility and building programs focused on measurable exposure reduction. 

Traditional operating systems (OS) were built to manage hardware, files, apps, and users on a device, but Cloudflare says the agentic AI era requires a whole new format.

The company this week announced Cloudflare OS, which connects AI agents, enterprise data and context, internal systems, and workflows together in one secure workspace. It is open source and browser-based, sparing companies the need to build all-new infrastructure.

The OS is launching alongside several other new security, identity, spending, and user insight tools that Cloudflare has built for the AI-based workplace.

“Cloudflare OS isn’t a traditional desktop OS,” said Rita Kozlov, VP of product at Cloudflare. “It reimagines the workplace computing environment for AI.”

Open source OS runs in a browser

Cloudflare OS serves as a secure, AI-equipped workspace that is plugged into internal company systems. Available now through Cloudflare’s open source repository, it is accessible directly in a browser, and runs inside an enterprise’s Cloudflare account.

“It is a browser-based workspace that begins with a conversation,” Kozlov explained. Users can ask an agent to research, create slides, spreadsheets, and documents, build full-stack apps, or automate workflows without the need for a terminal. Those outputs are then shareable, but kept in isolated databases with access controls.

Enterprises will soon be able to access the OS directly through Cloudflare or via a “select group” of partners that will build tailored offerings on Cloudflare’s architecture, the company says. Because it is open source, organizational processes, internal system connections, and context aren’t locked into a vendor product or AI model provider. Customers can use whatever models they choose.

Cloudflare OS is built on Cloudflare Workers, Dynamic Workers, Durable Objects, and Access, the company’s zero trust network access (ZTNA) tool that verifies every user and request. Agents start with zero permissions by default and are only granted access to tools required for a specific task. Organizations configure their own Access policies, models, branding, skills, and integrations, Kozlov explained.

Governed connectors known as gatekeepers give admins control over what AI can see, what it can change, and when the system needs human sign-off. They can also control budgets, set rate limits, and delegate tasks to different models.

“Because agents act on people’s behalf and produce work others can access and modify, they require a new security model,” Kozlov said. Thus, Cloudflare OS tracks the resources an agent requires so the right access controls follow its work when it is shared.

Cloudflare initially built the OS for internal use, and employees “across every team” use it daily. Kozlov estimated that, over the last 30 days, internal users have used it to create more than 4,000 apps, automations, and tools. Over that same period, she claimed, the company’s sales team saved an estimated 10,000 hours by automating previously manual tasks like territory planning and proposal creation.

“We open sourced Cloudflare OS so any organization can build ‘Your Company OS,’” Kozlov said. Open source is critical because “you cannot put your company into software you do not own. Organizations need to be able to inspect the platform, customize it, connect their own systems, and make it their own,” she explained.

A more cohesive bundle

Cloudflare deserves credit for packaging Cloudflare OS as an operating system, noted tech analyst Carmi Levy.

“This very much is not Windows, macOS, or Linux, and it isn’t an operating system by its common definition,” he said. “But Cloudflare’s use of this terminology implies familiarity to enterprise IT buyers.”

This makes for an easier discussion as enterprises struggle to understand how to best incorporate AI-related platforms and workflows into infrastructure that wasn’t initially designed for it.

Microsoft has marketed the combination of its Azure, Entra, Fabric, Windows, and Microsoft 365 offerings as an operating system of sorts, but hasn’t pulled all the pieces into a common brand, Levy said. And Google’s Gemini, Workspace, Vertex AI, and Cloud Run are “circling similar territory.”

But, he noted, Cloudflare OS is “more cohesively bundled” and infrastructure-focused, offering a single pane of glass platform for buyers worried about stitching together otherwise disparate AI-aware networking pieces. The company recognizes that AI introduces new architectural realities such as inference and model routing “over and above” traditional OS core competencies.

“While competing offerings generally leave the infrastructure heavy lifting to enterprise decision-makers, Cloudflare is marketing itself as a single-source vendor, which potentially frees IT planners from having to integrate all the AI pieces on their own,” Levy said.

An infrastructure-first, application-agnostic approach means Cloudflare OS can coexist with whatever AI applications already exist in an enterprise, he said. It will “play nice” with OpenAI, Anthropic, Google, Microsoft, Meta, or open source layers, allowing employees to begin working in familiar workflows after sign-in.

“Its open-source architecture also minimizes the potential for vendor lock-in as enterprises gradually figure out how to evolve their stacks to align with new AI-era realities,” Levy said.

Managing identities and budgets for both humans and AI

As AI agents emerge across the enterprise, tracking their use can be challenging, causing problems from both a security and a spend standpoint. Along with Cloudflare OS, the company has launched a way to address this issue with its new Identity-Aware AI Gateway, now in beta.

Also integrated with Access, the offering gives admins visibility into what users (both human and AI) are requesting from AI models. It allows security teams to set up custom domains in front of their gateways and replace shared API keys by integrating with their identity provider, like Okta or Entra, and ZTNA infrastructure, Cloudflare explained.

Every request is tied to Access-verified identities, and enterprises can filter each user’s logs, analytics, and spend. IT teams can track redundancies, limit usage rates, and apply filters that strip out employee names, passwords, and other sensitive data before requests go to outside model providers.

A companion feature, AI Spend, tracks every user’s behavior over time to create a baseline of normal AI usage. When spending deviates from that pattern, the system alerts the IT team.

A new tab, User Insights, tracks cost and identifies over-spend caused by activities such as low cache-hit rates or oversized context windows. The capability scores sessions and compares them against account history using a 95th percentile session cost over the previous 30 days, Cloudflare product managers Ming Lu, Kenny Johnson, and Ayush Kumar explain in a blog post. Anything above 2x an account’s 95th percentile is a “strong candidate for anomalous behavior.”

For instance, one Cloudflare customer had an employee who left a rogue AI session running, generating a $30K bill. “User Insights helped them identify the problem and shut off access before the problem was further exacerbated,” Kozlov said.

Cloudflare is also building prompt classification functionality that sorts requests into categories such as coding or writing. This can help enterprises understand what AI is being used for.

“Once business traffic is separated from everything else, personal use becomes visible,” the project managers explained. “From the outside, someone running a side hustle on company time and someone quietly moving data out through a model look the same. Telling them apart is central to catching insider risk.”

Looking at the bigger picture

Identity-Aware AI Gateway and AI Spend address the visibility problem that has dogged so many recent AI deployments where enterprises failed to monitor usage, Levy noted. Projects “crashed and burned” as users unwittingly blew through token allocations.

These platforms provide single-point visibility into what is being used, how it’s being used, and where the potential lies for raising the productivity bar, he said. They overlay with existing models; in doing so, they enhance security with more precise control over resource allocations, and via automated anonymization protocols that prevent inadvertent sharing of sensitive data.

Ultimately, he said, vendors who free IT from having to independently assemble the pieces of their own AI implementations, and who assist them with answers to AI-specific questions, “will gain advantage over vendors that aren’t looking at the bigger picture.

Traditional operating systems (OS) were built to manage hardware, files, apps, and users on a device, but Cloudflare says the agentic AI era requires a whole new format.

The company this week announced Cloudflare OS, which connects AI agents, enterprise data and context, internal systems, and workflows together in one secure workspace. It is open source and browser-based, sparing companies the need to build all-new infrastructure.

The OS is launching alongside several other new security, identity, spending, and user insight tools that Cloudflare has built for the AI-based workplace.

“Cloudflare OS isn’t a traditional desktop OS,” said Rita Kozlov, VP of product at Cloudflare. “It reimagines the workplace computing environment for AI.”

Open source OS runs in a browser

Cloudflare OS serves as a secure, AI-equipped workspace that is plugged into internal company systems. Available now through Cloudflare’s open source repository, it is accessible directly in a browser, and runs inside an enterprise’s Cloudflare account.

“It is a browser-based workspace that begins with a conversation,” Kozlov explained. Users can ask an agent to research, create slides, spreadsheets, and documents, build full-stack apps, or automate workflows without the need for a terminal. Those outputs are then shareable, but kept in isolated databases with access controls.

Enterprises will soon be able to access the OS directly through Cloudflare or via a “select group” of partners that will build tailored offerings on Cloudflare’s architecture, the company says. Because it is open source, organizational processes, internal system connections, and context aren’t locked into a vendor product or AI model provider. Customers can use whatever models they choose.

Cloudflare OS is built on Cloudflare Workers, Dynamic Workers, Durable Objects, and Access, the company’s zero trust network access (ZTNA) tool that verifies every user and request. Agents start with zero permissions by default and are only granted access to tools required for a specific task. Organizations configure their own Access policies, models, branding, skills, and integrations, Kozlov explained.

Governed connectors known as gatekeepers give admins control over what AI can see, what it can change, and when the system needs human sign-off. They can also control budgets, set rate limits, and delegate tasks to different models.

“Because agents act on people’s behalf and produce work others can access and modify, they require a new security model,” Kozlov said. Thus, Cloudflare OS tracks the resources an agent requires so the right access controls follow its work when it is shared.

Cloudflare initially built the OS for internal use, and employees “across every team” use it daily. Kozlov estimated that, over the last 30 days, internal users have used it to create more than 4,000 apps, automations, and tools. Over that same period, she claimed, the company’s sales team saved an estimated 10,000 hours by automating previously manual tasks like territory planning and proposal creation.

“We open sourced Cloudflare OS so any organization can build ‘Your Company OS,’” Kozlov said. Open source is critical because “you cannot put your company into software you do not own. Organizations need to be able to inspect the platform, customize it, connect their own systems, and make it their own,” she explained.

A more cohesive bundle

Cloudflare deserves credit for packaging Cloudflare OS as an operating system, noted tech analyst Carmi Levy.

“This very much is not Windows, macOS, or Linux, and it isn’t an operating system by its common definition,” he said. “But Cloudflare’s use of this terminology implies familiarity to enterprise IT buyers.”

This makes for an easier discussion as enterprises struggle to understand how to best incorporate AI-related platforms and workflows into infrastructure that wasn’t initially designed for it.

Microsoft has marketed the combination of its Azure, Entra, Fabric, Windows, and Microsoft 365 offerings as an operating system of sorts, but hasn’t pulled all the pieces into a common brand, Levy said. And Google’s Gemini, Workspace, Vertex AI, and Cloud Run are “circling similar territory.”

But, he noted, Cloudflare OS is “more cohesively bundled” and infrastructure-focused, offering a single pane of glass platform for buyers worried about stitching together otherwise disparate AI-aware networking pieces. The company recognizes that AI introduces new architectural realities such as inference and model routing “over and above” traditional OS core competencies.

“While competing offerings generally leave the infrastructure heavy lifting to enterprise decision-makers, Cloudflare is marketing itself as a single-source vendor, which potentially frees IT planners from having to integrate all the AI pieces on their own,” Levy said.

An infrastructure-first, application-agnostic approach means Cloudflare OS can coexist with whatever AI applications already exist in an enterprise, he said. It will “play nice” with OpenAI, Anthropic, Google, Microsoft, Meta, or open source layers, allowing employees to begin working in familiar workflows after sign-in.

“Its open-source architecture also minimizes the potential for vendor lock-in as enterprises gradually figure out how to evolve their stacks to align with new AI-era realities,” Levy said.

Managing identities and budgets for both humans and AI

As AI agents emerge across the enterprise, tracking their use can be challenging, causing problems from both a security and a spend standpoint. Along with Cloudflare OS, the company has launched a way to address this issue with its new Identity-Aware AI Gateway, now in beta.

Also integrated with Access, the offering gives admins visibility into what users (both human and AI) are requesting from AI models. It allows security teams to set up custom domains in front of their gateways and replace shared API keys by integrating with their identity provider, like Okta or Entra, and ZTNA infrastructure, Cloudflare explained.

Every request is tied to Access-verified identities, and enterprises can filter each user’s logs, analytics, and spend. IT teams can track redundancies, limit usage rates, and apply filters that strip out employee names, passwords, and other sensitive data before requests go to outside model providers.

A companion feature, AI Spend, tracks every user’s behavior over time to create a baseline of normal AI usage. When spending deviates from that pattern, the system alerts the IT team.

A new tab, User Insights, tracks cost and identifies over-spend caused by activities such as low cache-hit rates or oversized context windows. The capability scores sessions and compares them against account history using a 95th percentile session cost over the previous 30 days, Cloudflare product managers Ming Lu, Kenny Johnson, and Ayush Kumar explain in a blog post. Anything above 2x an account’s 95th percentile is a “strong candidate for anomalous behavior.”

For instance, one Cloudflare customer had an employee who left a rogue AI session running, generating a $30K bill. “User Insights helped them identify the problem and shut off access before the problem was further exacerbated,” Kozlov said.

Cloudflare is also building prompt classification functionality that sorts requests into categories such as coding or writing. This can help enterprises understand what AI is being used for.

“Once business traffic is separated from everything else, personal use becomes visible,” the project managers explained. “From the outside, someone running a side hustle on company time and someone quietly moving data out through a model look the same. Telling them apart is central to catching insider risk.”

Looking at the bigger picture

Identity-Aware AI Gateway and AI Spend address the visibility problem that has dogged so many recent AI deployments where enterprises failed to monitor usage, Levy noted. Projects “crashed and burned” as users unwittingly blew through token allocations.

These platforms provide single-point visibility into what is being used, how it’s being used, and where the potential lies for raising the productivity bar, he said. They overlay with existing models; in doing so, they enhance security with more precise control over resource allocations, and via automated anonymization protocols that prevent inadvertent sharing of sensitive data.

Ultimately, he said, vendors who free IT from having to independently assemble the pieces of their own AI implementations, and who assist them with answers to AI-specific questions, “will gain advantage over vendors that aren’t looking at the bigger picture.

For decades, Network Address Translation (NAT) has been the default way IP addresses are provided inside larger networks, as a means to deal with the challenges of IPv4 address availability.

The basic premise behind NAT is that private addresses stay private, but that assumption might not be entirely accurate anymore (if it ever really was). At Black Hat USA 2026, researcher Malcolm Stagg, an independent researcher and Synack Red Team member, disclosed NatJack, an attack class that manipulates the NAT connection tracking table. 

An attacker sharing a NAT boundary with a victim can hijack active connections, poison DNS responses, and force denial of service, without the IP spoofing or broadcast domain access older Layer 2 attacks required. Thirteen vendors were notified, and testing covered 32 products and configurations across 95 reports. Every tested implementation was vulnerable to some or all of the NatJack techniques.

Stagg didn’t intentionally set out to find flaws in NAT, but he found them. “I kind of ran into this attack entirely by accident,” Stagg told Network World. “I noticed that I was sometimes getting responses that didn’t correspond to the packets that I was sending. That told me that there is some sort of corruption happening inside the NAT table.”

What breaks in the NAT trust model

NAT was never built as a security control. It emerged in the early 1990s as a stopgap for IPv4 address exhaustion, letting multiple devices share one public IP address under an assumption of trust between peers.

“I think it basically goes back to under-specification in some of the RFCs that just allow behaviors based on the assumption that you’re in a network where the peers are trusted,” Stagg said.

NAT has been hacked before. Security researcher Samy Kamkar disclosed NAT Pinning at DEF CON 18 and Black Hat in 2010, an early technique for manipulating NAT port behavior. He returned to the problem a decade later with NAT Slipstreaming, disclosed in 2020 and expanded with Armis researchers in 2021, which abused Application Level Gateway (ALG) connection tracking and required a victim to visit a malicious website. Those flaws have all been patched.

NatJack is different. It manipulates the NAT table directly, needs no ALG, and requires no victim action beyond an active connection through the same NAT.

The flaw does not stop at Layer 2. VLAN segmentation and switch port isolation do not help, since the attack targets shared NAT infrastructure at Layer 3 and Layer 4 rather than the local broadcast domain. The flaw was confirmed across Windows, Linux, and macOS despite no shared NAT codebase, pointing to a shared design assumption rather than an isolated bug.

Four attack techniques, one shared weakness

NatJack covers four distinct techniques, all built on the same weakness in how NAT tables track connections.

• TCP connection hijacking. An attacker forces a victim’s connection into a closed state using spoofed packets, then replaces the resulting table entry with one pointing to the attacker. The RFC 1337 TIME-WAIT Assassination mechanism Stagg identified lets this happen in a handful of packets rather than a standard connection timeout.
• DNS response poisoning. The technique intercepts and alters UDP DNS responses passing through the NAT, redirecting a victim’s lookups without their knowledge.
• Denial of service. An attacker exhausts the NAT table itself, breaking connectivity for every device sharing that NAT.
• Connection port identification. An attacker determines which port a NAT has assigned to an active connection, information that can support the other three techniques.

Disclosure and a mixed vendor response

Stagg responsibly disclosed the flaw, though vendor reaction has varied widely, from formal patches to outright rejection. 

The Linux kernel security team initially dismissed the report, going so far as to call the report- totally bogus. Stagg said the response caught him off guard. “I was pretty surprised by that,” Stagg said. “Getting that response was a little bit unexpected, and a little discouraging.”

The kernel was eventually patched at Microsoft’s request to support Azure Kubernetes Service, resulting in CVE-2026-63913. Microsoft’s own Windows NAT vulnerability, affecting Hyper-V, was assigned CVE-2026-56181.

Other vendors declined to classify the findings as vulnerabilities. “These reports are design-level NAT limitations rather than security vulnerabilities,” Cisco PSIRT said. “There are documented mitigations for the Cisco Secure Firewall and Cisco IOS XE products which would prevent most, if not all of these issues.”

Apple took a similar position. “We’ve determined the behavior reflects a known limitation of the transport layer rather than a vulnerability,” Apple Product Security said. “Modern security models assume the local network may be hostile. This is why we continue to rely on end to end encryption, such as TLS.”

Stagg noted that while encryption blunts the worst outcomes of NatJack, it does not eliminate the risk. “Encryption is a great help here because an attacker can still hijack a connection, but if they do, they can’t send or receive any data over that connection unencrypted,” Stagg said. “An attacker can still target and remove any of those connections.”

Detection and mitigation

Even without full patches available, there are steps that network professionals can take to limit risk. Stagg suggests the following:

• Monitor for compromise indicators. Watch for a full or near-full NAT table, floods of TCP or UDP packets across a wide port range, the same IP address appearing at two physical locations, and anomalous SYN or RST packet sequences.
• Enable source IP protection. Turn on protections such as IP Source Guard to block spoofed packets at the router or firewall.
• Segment untrusted traffic. Place untrusted users on a separate subnet or VLAN, and cap connections per client at roughly under 10,000.
• Disable loose connection modes. Turn off loose connection tracking, port preservation, and endpoint-independent mapping where supported.
• Restrict container network access. Disable network access for untrusted containers and Kubernetes workloads, avoid running as root, and drop default capabilities.
• Isolate cloud workloads. Keep untrusted and trusted workloads off the same NAT gateway, and use dedicated IPs for serverless workloads.

“One of the attack variations does still work in cases where the attacker and victim are located in different subnets,” Stagg said.

Stagg said the underlying lesson of NatJack extends beyond any single patch.

“A lot of networks are vulnerable to this, and you can’t always rely on the Layer 2 isolations that are in place,” Stagg said. “When you’re relying on historical design choices, those threat models might not be the same now as they were back then. It’s important to look at those design assumptions and see if there are any updates that might be necessary based on the new threat models.”

AI note-taking app maker Granola is accused of violating privacy laws by developing software that can record conversations without all participants’ consent, according to a lawsuit filed July 30 in a California federal court.

It follows a similar ongoing case in the same district, filed last year, that involves another note-taking and transcription software vendor, Otter.ai.

AI note-taking apps have proliferated in recent years, with dedicated tools emerging from vendors including Fellow, Fireflies, Otter, and others, some of which claim to have tens of millions of users. These AI assistants record and transcribe meeting conversations, generating automated summaries and follow-up items. Similar note-taking functionality is also built into virtual meeting platforms such as Google Meet, Microsoft Teams, and Zoom.

However, the use of these AI note-taking tools has raised privacy concerns over the ability of some to record and transcribe conversations without the consent of all participants.

The proposed class action complaint against Granola, filed by Florida resident Tarra Chamberlain in the US District Court for the Northern District of California, alleges the company “purposefully” designed its app to record calls without requiring disclosure to all participants.  

While some note-taking tools require a bot to join a video or voice call, Granola captures audio directly from the user’s computer, allowing it to transcribe meetings without appearing as a meeting participant.

The complaint argues that this violates individual privacy rights as well as the California Invasion of Privacy Act (CIPA) that requires “all-party” consent when recording calls.

The complaint also alleges that Granola then by default uses transcription data for commercial purposes, including its use in training its AI models, and “actively advertises the hidden nature of its technology as one of its primary advantages.”

Granola did not respond to a request for comment.

According to the company’s website, Granola offers two optional “transparency features” that can be enabled by app users and admins: an automated chat message that alerts participants when transcription begins, and a watermark added to the user’s video feed. The company also promises that data used to train its AI models is anonymized and “never sent to third parties.”

The Granola case bears similarities to a separate lawsuit involving Otter.ai. The class action filed last year alleges that Otter.ai records all users without their consent and uses their voices to train its speech recognition AI tools.

Reporting on the latest developments in the Otter.ai suit, MLex wrote this week that, during a court hearing Monday, the judge overseeing the case expressed skepticism about the company’s argument to dismiss the case. US District Judge Eumi K. Lee did not issue a ruling from the bench, saying a written judgement would follow.

The two cases highlight some of the concerns businesses face when deploying AI note-taking tools.

AI notetaking is “more dangerous than any other type of traditional recording apps and tools,” said Enza Iannopollo, Forrester VP and principal analyst, as it raises additional questions about the use of employees’ conversation data.

“Specifically, is the recorded data used for training models? Is the voice used for training other AI? How do I get ‘forgotten’ after my data and biometrics have been recorded? These concerns apply to AI specifically and must be added to the traditional privacy and confidentiality concerns organizations have for other type of recording apps and tools,” she said.

Before deploying AI note-taking apps, Iannopollo recommends that businesses take appropriate steps to vet the tools and “ensure that all contractual clauses are aligned to the business AI risk appetite and risk management best practices.”

“As these tools record, process, store, and share biometric data, organizations must ensure that they comply with all the relevant requirements,” Iannopollo said, adding that transparency and consent notices should be provided to all parties involved in the use of AI note-taking apps.

Given the widespread enterprise adoption of passkeys to replace passwords, a Palo Alto Networks Unit 42 report disclosing ways attackers are getting around passkey protections is concerning, analysts say, but they stress that the demonstrated attacks can only happen after a successful intrusion.

They also pointed out that the issues are not strictly caused by holes in passkeys so much as by weaknesses in the procedures surrounding them. 

“The researchers didn’t break the underlying cryptography. They exploited the seams around it: onboarding flows, recovery mechanisms and trust signals that weren’t being validated,” said Justin Greis, CEO of consulting firm Acceligence. “That distinction matters because it tells us where the actual risk lives.”

The Palo Alto report showed attacks that, it said, “demonstrate how malware on a compromised endpoint can misuse onboarding, recovery and device trust workflows to take over passkey-protected accounts,” as well as “how an attacker can authenticate without user interaction, bypass user verification requirements and extract all synced passkey private keys.”

Palo Alto described three categories of attack, collectively dubbed Pass-ta-key: Pass-ta-key, where an attacker takes over an account protected by a Google-synced passkey using malware running on the victim’s device, without requiring privilege escalation, device unlock or user interaction; Silver Pass-ta-key, which involves an attacker tricking Google Cloud Authenticator into believing the victim has unlocked the device with biometrics, leading to full account takeover without using the victim’s device during authentication; and Golden Pass-ta-key, which allows an attacker to extract all synced passkeys in a form that lets them be shared or sold on the credential black market.

Given the complexity of most global enterprise threat surfaces, some CISOs have struggled with adapting passwordless processes to environments with legacy and virtual environments. Passcodes have been recently embraced by enterprise CISOs as the first step in implementing a passwordless strategy.

Analysts and consultants in the main agreed that the flaw Palo Alto reports is significant, despite the fact that it assumes the attacker has already penetrated an environment and successfully installed malware. Sadly, given that such penetration only requires one privileged user anywhere to accidentally click on a poisoned link or attachment, the assumption of prior penetration is likely valid.

Implementation issues are the problem

What the report reveals is less about any flaws within passcodes directly, and more about the lack of attention paid to a wide range of mechanisms surrounding them. 

Greis said CISOs now need to focus on what to do, and what to test, based on the assumption that user behavior is not always as expected. 

In several cases cited in the report, he pointed out, issues occurred “not because the standard is flawed, but because implementations haven’t caught up to it. It mirrors what we’ve seen repeatedly in security: the specification is sound, but the ecosystem implementing it is uneven.”

Consultant Brian Levine, executive director of FormerGov, agreed. 

“On any service where your organization is the relying party, require user verification and actually validate the user-verified flag in the authentication response,” he said. “The researchers found real-world services accepting logins without it, which quietly collapses a multi-factor login back into a single factor.”

Frank Dickson, group VP for security at IDC, added that he would stress to CISOs that this attack assumes a prior successful penetration. 

“This isn’t passkeys getting hacked from across the internet. It’s what [an attacker] does once they’re already inside the house. So the real headline is that ‘phishing resistant’ stops being resistant the moment the endpoint stops being clean,” he said.

“Stop treating verification as optional,” he advised. “Flip it to required, check it server side every single time, and save your hardware bound keys, the YubiKeys of the world, for the accounts that matter most. A key that never leaves a physical device is a key no attacker can ever harvest in bulk.”

Or Finkelstein, head of marketing at Secret Double Octopus, agreed that CISOs have gotten complacent about the way in which systems support passkeys.

“CISOs should probably look at how user verification is enforced, how enrollment and recovery work, have a clear and enforced policy on whether credentials are synced or device-bound, and have some ITDR system to quickly mitigate suspicious endpoints and authenticators,” he said. “In most serious enterprise environments, EDR and device management reduce the likelihood of initial attacks, but do not close every post-compromise attack path.”

Poor support processes weaken passkeys

Some have argued that the lack of sufficiently robust support processes actually weakens passkey capabilities and undermines the whole point of such systems.

J. Wolfgang Goerlich, a member of the faculty of IANS and a longtime cybersecurity consultant, pointed out that the original FIDO2 spec eliminated credential theft by binding the private key to a physical authenticator. Synced passkeys reintroduced credential portability and therefore reintroduced the form of credential theft risk cited in the Palo Alto report.

“A passwordless system is exactly as strong as the flow that re-establishes it,” he said. “Both serious techniques here start by forcing a device to re-enroll. Many security teams have never modeled, never monitored and never rehearsed a response to this.”

Goerlich’s advice to CISOs is to require device-bound authenticators, such as hardware tokens or computers, for all privileged and sensitive access. They may consider allowing wallets for lower risk access, he said, “however, much like passwords in Web browsers have long been at risk, we must now consider passkeys in the browsers an unacceptable risk.”

This article originally appeared on CSOonline.