The conversation about agentic AI is shifting: Rather than focusing solely on what the technology can produce, IT leaders are now considering what they are prepared to let it do.
Unlike traditional AI assistants that primarily respond to user prompts, agentic AI systems can make decisions and execute actions autonomously across business processes. This creates opportunities to accelerate workflows and improve productivity but also introduces new challenges involving risk and organizational readiness.
The shift is already well under way. In a recent HCLTech survey, 87% of the participating enterprises reported using generative or agentic AI in IT operations, underscoring the growing importance of effective governance. These challenges were central to a recent HCLTech and Google Cloud roundtable on the business impact of agentic AI in which the participants explored what it takes to move from experimentation toward enterprise-wide adoption.
Agentic AI is showing promise across a wide range of business functions, including IT operations, software engineering, customer experience, HR, marketing, finance, and sustainability. Across these areas, intelligent agents can streamline complex workflows; automate routine tasks; and support faster, more informed decision-making.
Realizing potential
But realizing that potential requires more than deploying new technology. Successful implementations begin with identifying high-value use cases, establishing measurable key performance indicators (KPIs), and connecting AI initiatives to specific business outcomes.
Roundtable participants highlighted concerns about cost, ROI, and insufficient testing, reinforcing the importance of a measured approach to adoption. To manage these risks, organizations are typically starting with lower-risk business processes, demonstrating tangible value before expanding their use of autonomous agents as confidence and capabilities mature. Those concerns are reflected in HCLTech’s AI Impact Imperatives 2026 research, conducted by Omdia, which found that respondents expect approximately 43% of their major AI initiatives to fail.
Rethinking governance for autonomous systems
As AI moves from assisting employees to acting on their behalf, traditional approaches to governance and compliance may prove inadequate. Autonomous agents introduce operational and reputational risks that require organizations to reconsider how decisions are monitored, audited, and controlled.
Governance must be built into agentic AI initiatives from the outset rather than added after deployment. That includes establishing clear boundaries for autonomous agents and determining where human intervention remains necessary. Human oversight is particularly important in high-stakes areas such as financial transactions, regulatory compliance, cybersecurity, and decisions affecting customers or employees. The appropriate level of oversight should reflect the potential business impact and risk associated with an agent’s actions.
Clear accountability, transparent decision-making, and escalation mechanisms can help organizations balance greater autonomy with continued human control over critical decisions.
Preparing for new ways of working
Technology alone won’t determine whether agentic AI succeeds at enterprise scale. Organizational readiness is another major hurdle, requiring businesses to align data, governance, people, and processes around common objectives. Change management and AI literacy are particularly important. Employees across technical and nontechnical roles will need new skills to supervise agents, evaluate their decisions, and collaborate effectively with autonomous systems.
As agents become increasingly integrated into business operations, organizations will also need to reconsider how their performance is managed and measured. Over the next several years, enterprises may see the emergence of hybrid teams in which employees focus more heavily on strategic decisions and oversight while AI agents take on more operational responsibilities.
Achieving this vision will require organizations to rethink operating models and invest in workforce readiness alongside technology. Ultimately, the autonomous enterprise will be defined by how effectively AI agents are integrated into business operations and deliver measurable results, rather than simply by how many agents an organization deploys.
Learn more about how HCLTech and Google Cloud are helping enterprises navigate the transition to agentic AI.
In an industrial network, malicious activity can be hard to tell apart from normal data exchange between devices. Malicious actors routinely rely on legitimate tools and the Living-off-the-Land technique, so a single network connection may show no known signs of an attack: the device uses a familiar protocol and transmits ordinary data. An anomaly can hide in subtle details: the data source, the time of access, or the volume of transferred data may be atypical for a particular device. However, to detect this kind of anomaly, you need to understand the roles of the devices at both ends of the connection and know which network activity patterns are typical for them.
But an organization’s asset inventory data is often incomplete, which makes it harder to catch unauthorized connections in time. Suppose monitoring detects a host that regularly exchanges data with programmable logic controllers (PLCs). Its IP address is known, but the inventory does not specify what role it plays: is it an engineering workstation, a process data server, or a piece of contractor’s equipment? The host may also have been on the industrial network for a long time, with its record going out of date after a network upgrade.
In the joint OT asset inventory guidance released by CISA and its partners in 2025, inventorying devices and classifying them by role are treated as part of OT asset management. For organizations, this is one of the most important areas: according to the SANS 2025 ICS security survey, 50% of respondents had deployed or significantly expanded ICS inventory and visibility tools over the previous 12 months, and 54% named them as investment priorities for the next 12–24 months.
Device inventory in Kaspersky Industrial CyberSecurity for Networks
In Kaspersky Industrial CyberSecurity for Networks, the Asset Discovery technology is the foundation of asset visibility. Passive network traffic analysis detects devices and their interactions, while recognition rules help determine the device category and extract available information about it, such as the vendor, model, or software version. Exactly which attributes the system can obtain depends on the protocol and the traffic it observes. We covered this in more detail at the Kaspersky Industrial Cybersecurity Conference.
Hardware and software information in the device card
The product also supports active polling modules (APMs): where polling is allowed, they can request additional configuration and firmware version details from devices. This kind of inventory is far more detailed than a list of IP addresses.
Installed modules and their placement in a PLC rack
However, even accurate hardware information doesn’t always explain what function a host performs in a specific industrial facility. Gaps appear for various reasons. Some devices send identifying information only at startup or during configuration, while others rarely communicate. Proprietary protocols can’t always be parsed, and encryption may leave only connection metadata for analysis. If the monitoring system doesn’t receive traffic from every segment of the industrial network, some network activity goes unobserved. Active polling doesn’t suit every device or every operating condition.
Devices of unknown category
When there isn’t enough direct information about a device, its category can be refined by looking at the patterns of its recurring network interactions. Analyzing these interactions is the job of Machine Learning Event Processor (MLEP), a service included in Kaspersky Industrial CyberSecurity for Networks 5.0. This machine-learning-based event processor can both refine device categories and detect anomalies in their network behavior.
What data does MLEP analyze?
To compare device behavior, you don’t need to store every packet as a separate observation (a data object) in the ML model. MLEP represents network sessions as a sequence of short 15-second fragments. For each fragment, MLEP stores information about the endpoints (IP, MAC, and port), the direction of data exchange, the protocol, and the number and size of the packets transmitted. Together these make up an event, which then gets a timestamp. Traffic thus becomes a sequence of events showing which hosts a device communicated with, when, and how communication intensity changed.
Aggregating data into events also sets the method’s limits. An aggregated fragment can’t be used to reconstruct the exact order of individual packets or the content of commands. MLEP can draw conclusions about a new protocol only if another KICS technology has managed to recognize it. That said, comparing stable network connections and changes in exchange volume doesn’t require a detailed record of every packet. These observations form the basis of the device’s behavioral history.
From observations to MLEP results
Each object has its own behavioral history, and one object’s history can’t be applied to another. But the principles of behavior analysis, along with some common rules, work across different objects.
Let’s look at how this works in MLEP, which is built on a spiking neural semantic network (NSN).
Event identification
Neurosemantic networks structure information as a multilayer ordered graph, where the data in each consecutive layer builds on the data in the previous one. The nodes of this graph — that is, the units of information in each layer — act as neurons.The NSN creates dedicated channels to handle different event parameters (port, IP, and so on). Unique parameter values for each channel are stored as neurons in layer 0. The event itself, which consists of a set of parameter values, is stored as a neuron in layer 1 of the network. If an event occurs for the first time, neurogenesis creates a new neuron with input connections to the corresponding parameter neurons. This lets the network learn and operate on the event stream at the same time. If the event has occurred before, the network activates the same neuron that was created when the event first appeared. This way, the network identifies each event precisely. Each neuron that corresponds to an event also collects basic statistics: when it was last activated and how many times it has been activated.
Event history
In NSN-based event processing, layer 2 and above store sequences of events over time: recurring patterns and the full history. However, categorization and statistical anomaly detection don’t require storing the full packet sequence or a detailed timeline of every network event. As we noted earlier, events are themselves aggregates, which means the order of network packets has already been averaged out. So MLEP keeps history only temporarily, within each episode (30,000 aggregated events by default), which saves computing resources.
Statistics processing in MLEP
MLEP processes statistics mainly through specialized listener neurons on layer −1 (minus one) of the network. Attention heads and monitors are built on these neurons.
Key components of the NSN
When an event arrives, the corresponding neuron is activated, and the network instantly knows whether that neuron is new or was created earlier. Each attention head subscribes to the events or event features it needs and takes in only the activations of the matching neurons. If an event occurs for the first time, all heads are notified and then decide whether to subscribe (grow a connection to the relevant neuron) and receive information about activations of such neurons from then on.
It is called a spiking network because activation information is a spike, not a number. This spike tells the head that something it’s interested in has happened.
An attention head is configured according to scenarios — the situations that MLEP should send alerts about. The core of a head’s configuration is a query, which filters incoming information and serves as the subscription criterion. Unlike regular database queries, this query runs on the stream, so it can react to an event instantly.
Attention heads work very much like the semantics of ordinary human language. A query has a subject of attention (one or more grammatical subjects) and conditions (the other parts of the sentence). In the infrastructure of an industrial enterprise, the subjects are devices on the network, and the conditions are various aspects of network communication, such as ports, protocol, and average packet size. If a head has many subjects (for example, if it’s interested in every device on an industrial network), it fans out: it creates a child head for each individual value of the subject of attention, that is, each device. The child head then watches a specific device and reports to the parent head.
Attention heads don’t accumulate or process statistics. They only filter event streams. When an attention head receives a relevant event, it activates and sends a spike to the monitor subscribed to that head.
Monitors, in turn, have stacks for accumulating and processing events. They can also have their own queries and post-filter information from the head. For example, they can select only new events from those filtered by the head.
There are several types of monitors:
Stat monitors track changes in the average count of specific events (for example, device activity) over time intervals typical for those events, or in the average values of numeric event parameters (for example, changes in device traffic volume).
Monitors work from the event alone: they fire when an event has occurred a certain number of times within a given interval, or has occurred for the first time.
Similar-behavior monitors work with heads that can generalize events, that is, extract just a few parameters whose combination is shared (generalized) across many events.
MLEP uses these monitor types to implement scenarios for categorizing devices and detecting their anomalous behavior:
For categorization, MLEP uses attention heads and monitors that identify common behavior across different assets and group devices accordingly. MLEP then takes information from Asset Discovery about the known categories of some assets and extends those categories to other assets in the same group. Because a device can show different types of activity, it may land in several groups. MLEP then makes a weighted assessment across all relevant groups.
Groups of devices with similar network behavior
At the final stage, the system verifies that assigning the category to the asset is permissible. This is again done by special rule monitors loaded into the NSN at system startup. The rules rely on asset metadata available from Asset Discovery and APMs.
MLEP takes a similar approach to anomaly detection: an attention head and a monitor define an anomaly scenario, often loosely. When a monitor activates on such a scenario, MLEP generates an alert about unusual behavior.
The current version of MLEP ships with preconfigured heads and monitors.
The functional dynamic diagram below shows how events from devices on an industrial network are processed.
Event processing flow (click to play)
MLEP in practice: how behavior helps complete the asset inventory
At a facility with several similar production lines, device information may be more complete on some lines than on others. On one line, devices are identified as PLCs, while on another, after an upgrade, some hosts show up only as addresses: the available traffic didn’t provide enough information to determine their category. Still, these devices communicate with the same types of HMIs and process data collection servers. Their communication directions, frequency, and volumes may be similar.
That’s where MLEP comes in. It takes the categories of already known assets and matches recurring features of their network behavior against those of uncategorized devices. When the observed interactions turn out to be similar, MLEP can add a category for that host to the inventory.
Device category suggested by MLEP
Once the category is refined, the industrial network map provides more context about the equipment on the network. When analyzing network activity, the analyst immediately sees the device’s suggested category and can skip looking up each IP address in the design diagrams. This approach is especially useful where equipment changes faster than the documentation is updated.
The suggested category is also checked against existing device information and defined constraints. This helps filter out some contradictory options, but prediction quality still depends on how much of the traffic is visible, especially if the device communicates only rarely.
Anomalous activity and streaming statistics
Investigations of real-world attacks show that attackers actively use both standard tools and permitted protocols. You don’t always need to know an attacker’s specific technique in advance to spot potentially malicious activity. Signature-based detection helps find known signs of an attack, but it doesn’t assess how typical an observed interaction is for a particular device. MLEP compares current activity with the device’s usual network profile: which hosts it communicates with, which protocols it uses, when and how much data it transmits, its average packet size, and so on. The changes it detects help guide the direction of the investigation. Correlating these changes with other events and the operational context helps determine whether malicious actions could be behind them. When investigating an incident that has already been detected, anomalies help reconstruct the sequence of actions.
The first version of MLEP comes with six preconfigured monitors, one for each type of deviation from the device’s usual network profile:
Anomaly
How it helps with event analysis
New external host
Flags a new external connection that wasn’t previously seen in the device’s observed behavior, even if the IP address isn’t listed among known IoCs. Helps check whether this connection appeared at the same time as other suspicious events.
New combination of destination address and port
Shows that the device has begun using a service it hasn’t used before. Once an incident has been detected, this helps trace new connections after the more critical events have been analyzed.
Unusually large volume of data sent
Highlights data transfers that are atypical for the device and helps correlate their timing and direction with other events.
Atypical activity time
Shows that the device was active at a time that’s unusual for it. In an already detected incident, this helps reconstruct the timeline of actions around the main alert.
New protocol
Helps spot a new method of communication, even when the device is communicating with familiar hosts.
Activity with signs of scanning
Shows that the device has started contacting an unusually large number of neighboring hosts. This signal helps reveal possible reconnaissance ahead of attempts to access equipment.
During an investigation, anomalies help reconstruct the sequence of changes: when a specific host established new connections, switched protocols, increased its data transfer volume, or shifted its operating hours. Matching events by device and time shows an analyst how activity unfolded around an incident that has already been detected.
This is especially useful when some of the attacker’s actions fell outside the monitored scope or didn’t trigger other KICS technologies. Correlating these changes with the device’s role, protocol analysis data, and events from other technologies gives the analyst a more complete timeline. Behavioral anomalies show exactly where to look for the missing links and which network interactions need attention.
Atypical Activity Time anomaly card
In the event list, anomalies detected by MLEP are marked with an AI label. Each event shows its name, source, destination, timestamp, and the ID of the triggered scenario.
Conclusion
In an industrial network, whether behavior is anomalous depends on the host where it occurs and that host’s place in the industrial process. The repetitive nature of many communications makes a change in normal data exchange easier to spot, while knowing a device’s function and criticality helps gauge the possible consequences. Taken together, these observations make network traffic more than a list of connections: it helps assess new events in the context of a specific facility, even without an attack scenario known in advance. Machine learning technologies are well suited to this kind of comprehensive analysis, as they can process and organize huge streams of heterogeneous data. Starting with version 5.0, Kaspersky Industrial CyberSecurity for Networks handles this function with MLEP, which works effectively alongside the product’s existing functionality.
As part of proactive threat monitoring, Kaspersky’s Cyber Threat Intelligence team identified a malicious campaign involving C2 agents controlled by artificial intelligence. Confirmed victims of the campaign included organizations in the education sector in several countries across Africa and Latin America. CyberStrikeAI played a key role in the post-exploitation phase. This is an open-source framework in which an LLM orchestrator on the command-and-control server plans actions, selects tools, and generates commands, while an implant executes them on compromised hosts. Using CyberStrikeAI, the attackers progressed from reconnaissance to full domain compromise.
According to our data, this is one of the first public descriptions of a compromise involving an LLM in the wild. The campaign we discovered clearly illustrates how the role of AI in attackers’ arsenals is evolving: until recently, language models were used primarily during preparatory stages – for writing phishing emails, debugging code, or searching for vulnerabilities. Now, however, they are being embedded into the very core of the attack, automating actions at every stage: payload execution, persistence on the host, discovery, lateral movement, and, finally, data collection and exfiltration. Post-exploitation – the stage that traditionally required manual work by an experienced operator – plays a particularly significant role here.
A key feature of the scheme using the CyberStrikeAI framework is that the implant ceases to be a simple tool for executing the operator’s commands. Decisions are distributed across two levels: the operator defines the task in general terms, while the model determines how to execute it – specifically, which commands to send to the host and in what sequence. Thus, the strategic planning remains with the human, while the choice of technical steps is delegated to the model, and the implant executes the model’s decisions.
To understand how this scheme works in practice, let’s examine the chain of actions taken by the attackers, as reconstructed by our analysts during the incident investigation.
Timeline of the attack
Let’s examine the timeline of the attack using an example from one incident within the detected campaign.
The first phase follows a standard approach: a human operator gains access to the victim’s infrastructure via a compromised SQL Server (version 16.0.1000), then collects basic information about the host, deploys tools, and conducts network reconnaissance. All of this activity takes nearly a day, followed by a two-week pause.
The second phase is fundamentally different. The first step involves deploying the CyberStrikeAI C2 agent, which receives commands from a server-based LLM orchestrator. During the second phase, the agent performs the following:
establishing persistence and conducting local reconnaissance within 2 minutes;
conducting domain reconnaissance over the next 5 hours;
after a brief pause of several days, moving on to the final stage – lateral movement via SMB and WMI, mass credential dumping on hosts, and database export – with the entire operation taking no more than one hour.
We’ll discuss these stages in more detail in the next section.
Technical details
CyberStrikeAI overview
CyberStrikeAI is an open-source, modular platform written in Go for automating penetration testing. Its key feature is combining LLM-based attack orchestration and a built-in C2 server with agents (beacons) within a single server process.
The entire “intelligent” layer is isolated on the control server. C2 functions (calling reconnaissance and exploitation utilities, managing webshell connections, assigning tasks to agents, and reading results) are available to the model as MCP tools. The implant is a classic C2 agent with no AI functionality – no API keys, no calls to AI service APIs, and no autonomous logic. It periodically polls the listener server via HTTP/S, TCP, or WebSocket, executes shell commands, and interacts with the file system. To the victim, this activity looks like a typical remote-control session, where a server-side LLM orchestrator queues tasks instead of a live operator. The LLM influences how decisions are made, but not how the corresponding commands are delivered to the host.
Although CyberStrikeAI is publicly available, specific instances of the framework can be linked to specific attackers or campaigns. Detection and attribution are possible based on the following artifacts:
Control panel: Upon launch, a self-signed TLS certificate is generated, with the framework’s name appearing in the issuer and subject fields. The certificate is created in memory at each startup, so the not_before field effectively records the time the process was launched. Accordingly, as with Cobalt Strike, the chronology of restarts can be reconstructed from the scan history.
CyberStrikeAI control panel’s self-signed TLS certificate
Implant: The build metadata (go version -m) contains a path to the main package, which includes data pointing to the built-in CyberStrikeAI generator – a temporary directory with the build identifier. This path is identical for all payloads, making it a reliable signature. Additionally, the build info field contains version control system metadata, which can be used to compare samples against one another.
Authentication: When communicating with the server, the implant sends an X-Implant-Token header with a fixed value in the HTTP request. The token is unique to each C2 server and is embedded into the malicious payload during the build phase; therefore, it serves as both a network indicator and a sign that the samples belong to the same server.
HTTP header parameters sent by the implant to the server
It should be noted that the implant version does not reflect the server version. The implant can operate for months while the operator updates the server-side components: listener configurations and keys are preserved during updates. In the incidents we detected, we observed the use of a single agent version throughout the entire incident. In such cases, the sample’s build date may indicate the earliest possible deployment date of the CyberStrikeAI infrastructure, but it still does not provide an estimate of the compromise duration.
Execution & Privilege Escalation
The first malicious commands on the victims’ systems in the campaign under investigation originated from the sqlservr.exe process, indicating the likely initial access vector and the context in which the attackers gained the ability to execute code. It is important to note that the commands marked as having been executed prior to agent installation were executed manually by the attacker specifically within the context of this process. At this stage, we are not yet dealing with automated implant activity, but rather with manual actions by the operator.
Before launching the agent on the machines, the attackers checked for its presence using a PowerShell script, from which we can deduce its default deployment paths: C:\Windows\Temp\, C:\Windows\, C:\ProgramData\, C:\Temp. At the same time, the attacker can disguise the agent’s name as that of a legitimate system process. In the example below, it mimics svchost.exe (svchosts.exe)
Checking for the presence of the CyberStrikeAI agent on the system
Delivery and execution of the CyberStrikeAI agent
Like most C2 agents for Windows, CyberStrikeAI uses PowerShell to execute its payload. When a request is received from the operator, the commands to be executed are additionally encoded in Base64 to bypass keyword-based detection.
Decoded form of the command:
When administrative privileges were available (for example, a domain administrator account), instead of executing commands directly, the agent on remote hosts often created scheduled tasks so that the malicious payload would run with SYSTEM privileges:
An alternative method that does not use schtasks utility is to create a task via the Schedule.Service COM object:
The payload (p1.ps1) from the example above is a reverse shell that connects to the server at 185.186.245[.]144:5501:
The p1.ps1 payload and similar scripts were distributed across the network using shared network administrative folders and the WMI protocol, which we will describe in more detail in the Lateral Movement section.
Stealth
In addition to encoding commands in Base64 and obfuscating SQL/LDAP queries – which we will describe in the Collection & Exfiltration and Discovery sections, respectively – the attackers split the malicious payload into multiple files. It is noteworthy that the scripts were transmitted in this manner even before the agent was installed – that is, at a stage where human intervention is typically required – yet they clearly bear the hallmarks of being generated by an LLM.
Below is a sequential record of several script fragments written to the file d3.b64.
Subsequently, the attackers used the certutil utility to decode the resulting file and executed it with the following command:
Once assembled and decoded, the script’s contents looked like this:
The script is a tool for decrypting DPAPI secrets from the file C:\ProgramData\dsn_line.txt. This file, in turn, is populated by the following command, which searches for a DSN string containing connection settings in the SQL Server Reporting Services configuration file rsreportserver.config and copies its contents to dsn_line.txt.
It is worth noting that some of the scripts delivered and executed as described above contain comments in Chinese (## – researcher’s comments).
Persistence
If the CyberStrikeAI implant was successfully delivered, the first step was to establish persistence on the target system. To do this, the agent created a scheduled task named SystemUpdate, which specified the path to the implant as the action to be performed:
Analysis of the framework’s source code revealed an alternative method of persistence: by adding a value to the registry key HKCU\Software\Microsoft\Windows\CurrentVersion\Run, where the name of the created value matches the task name (SystemUpdate).
Agent persistence on Linux systems is also implemented in two ways – by adding the entry @reboot <path_to_beacon> & to the user’s crontab (in which case the process runs at system startup), or by adding the line (nohup <path_to_beacon> &>/dev/null &) to ~/.bashrc (in which case the agent starts when an interactive bash shell is opened).
It is worth noting that the choice of a specific persistence method is delegated to the LLM connected to CyberStrikeAI. However, thanks to the human-in-the-loop (HITL) mechanism, the operator retains full control over the process: commands generated by the model may require manual approval or correction before they are executed.
Discovery
Local Discovery
Before installing the agent on a compromised host, the attackers manually gathered basic system information using a fairly trivial set of commands:
The attackers also manually checked for internet access and obtained the external IP addresses of the compromised machines using the Chinese service dnslog[.]cn. The service generates a random third-level domain, after which the attackers attempt to resolve it on the compromised machine.
If the machine has internet access, the request succeeds, and the attackers obtain the external IP address of the compromised device on the service’s page.
For reconnaissance purposes, the agent generates a more complex script designed to map out a path for further privilege escalation by compromising SCCM or exploiting msiexec (the AlwaysInstallElevated key):
Additionally, to find ways to elevate privileges locally, the agent executed scripts to inventory services running under domain accounts and tasks running under the SYSTEM account:
During their activity, the attackers periodically checked for Microsoft Defender detections:
Remote Discovery
After gathering information about the compromised host, the attackers proceeded to conduct reconnaissance within the network. During the preparatory phase of the attack, they manually collected additional information about remote hosts using the net.exe utility.
During the main phase, the agent used PowerShell’s built-in functionality to detect accessible hosts without relying on additional utilities (such as nmap or fscan):
Additionally, relevant LDAP queries to Active Directory objects helped build a network map:
Furthermore, the presence of the installed agent on remote hosts was verified using WMI:
Domain Discovery
The next step was to gather information about the victims’ domains. To this end, before installing the agent, the attackers used standard OS utilities:
However, later on, using the CyberStrikeAI implant, reconnaissance was carried out via generated PowerShell scripts:
In addition to basic domain information, the agent performed LDAP queries to gather information for Kerberoasting and AS-REP Roasting attacks:
Finally, the agent was used to check the domain for the presence of LAPS and Microsoft Azure:
To detect signs of Microsoft Azure usage within the infrastructure, the attackers also searched for the .azcopy directory – created by the AzCopy (Microsoft Azure Storage Copy) utility – in users’ home directories:
Credential Access
After successfully conducting reconnaissance and mapping the network, the attackers moved on to the next stage – dumping credentials. For this purpose, the agent used a classic set of LOLBINs and well-known third-party tools.
The agent dumped registry hives containing credentials using the reg.exe utility:
The agent dumped the lsass.exe process using the MiniDump function of the comsvcs.dll library. In doing so, the target process’s PID was used instead of its name to make static detection based on the command line more difficult:
After successfully compromising privileged domain accounts (specifically, the built-in domain administrator), the attackers also carried out DCSync and Golden Ticket attacks via the agent using a renamed version of the mimikatz utility:
Lateral Movement
To spread across the network using compromised accounts, the attackers employed utilities from the Impacket toolkit, specifically WMIExec, as indicated by the utility’s characteristic command line:
Once installed, the agent prefers to use standard OS mechanisms, such as shared network folders.
Another method the agent uses to remotely execute commands is the WMI protocol. In particular, the agent used it to distribute the aforementioned p1.ps1 reverse shell script. This involved using compromised user accounts with local administrator privileges on the target hosts:
A second method of lateral movement via WMI uses the Invoke-CimMethod cmdlet:
Command & Control
To deliver the aforementioned tools (malicious scripts, mimikatz, and the agent itself) to the initial nodes in the infection chain, the attackers used standard OS utilities:
After the agent is installed, it checks the availability of the C2 server’s ports. The implementation mechanisms here are virtually unlimited and depend on the “creativity” of the respective LLM agents connected to the server:
To download additional utilities, the CyberStrikeAI implant also used built-in utilities (LOLBINs). The tools could be hosted on the attackers’ own servers or downloaded directly from GitHub:
Collection & Exfiltration
The data collection phase deserves special attention. It demonstrates yet another capability of LLM orchestration – the automatic generation of SQL and LDAP queries tailored to a specific task.
In one incident during the campaign, the attackers deployed the CyberStrikeAI implant on an educational organization’s SQL server and collected information from the database via PowerShell. Here is an example of a command executed by the agent:
Normalized view of the executed script with comments:
Before accessing the data, the agent checked the privileges of the account under which it connected to the database:
In decoded form, the check looks as follows:
On network resources, file collection was preceded by a recursive directory scan to identify files of interest.
To interact with the file system, the implant provides a built-in interface that supports direct uploading and downloading of files. Files are transferred directly via the main encrypted communication channel with the C2 server (HTTP or TCP), and the data itself is encoded in Base64 and packaged into the agent’s standard JSON responses.
Another built-in capability of the implant is taking screenshots of the infected machine. As with other actions, the implant does not initiate this on its own: the command to capture the screen is issued by the LLM orchestrator, and the agent merely executes it and returns the result via the same control channel.
On Windows, the command for taking screenshots looks like this:
The Linux version looks like this:
In the incidents we detected, data collection was the final stage of the attack: the chain ended there, and we observed no further activity.
Attribution
The key artifact for attribution in this campaign is the implant’s build metadata. The attackers built the malicious payload inside a Git clone of the project, so the Go compiler embedded version control system information into the binary files – the hash and commit time, as well as the vcs.modified=true flag (analogous to the +dirty suffix) – indicating uncommitted local changes in the working copy. The combination of these fields forms a unique fingerprint for a specific build.
Based on this fingerprint, the samples are divided into two independent groups, in each of which the Windows implant and the Linux implant have completely identical build metadata. A match indicates that, within each group, both payloads were built from the same project working copy.
Identical build metadata for the Windows and Linux implant samples, indicating a shared build environment
However, these groups do not overlap with one another. They do not share a common C2 infrastructure, and different versions of CyberStrikeAI are deployed on the command-and-control servers. In other words, the build metadata reliably links the samples within each group but does not provide grounds for linking the two groups together.
Differences in CyberStrikeAI versions on the command-and-control servers
The available data does not allow us to link the activity to any known group of attackers, nor to state with certainty that the same operator is behind both campaigns. Two factors prevent this. First, the tool’s openness: CyberStrikeAI is publicly available, so different operators could have independently deployed it and assembled malicious payloads under similar conditions. Second, command generation by the model: the “signature” characteristic of a specific operator is largely shaped not by a human but by an LLM. On the one hand, this increases the diversity of commands: the same command, when generated multiple times, can look different. On the other hand, it strips them of their individual characteristics, which reduces the value of behavioral metrics for attribution.
However, the Chinese-language comments found in the attackers’ scripts and the use of Chinese services still suggest a connection between the activity and a Chinese-speaking operator. In addition, analysts noted the timing of the control servers’ restarts: since the self-signed TLS certificate is regenerated each time the process starts, its not_before field records the restart time, and most of these restarts occurred during business hours in the UTC+8 time zone.
The origin of the tool itself also indirectly points in the same direction: CyberStrikeAI was developed within the Chinese cybersecurity community and is well known there.
In summary
CyberStrikeAI is a telling – though not unique – example of a shift occurring within the class of C2 frameworks: the LLM orchestrator is no longer merely an add-on to reconnaissance but has become a control layer over post-exploitation. If HexStrike AI and similar tools cover the “find and break” phase, and Sliver/Mythic/Havoc cover the “establish a foothold and control” phase, CyberStrikeAI completes the kill chain: a single server-side process written in Go executes utilities via MCP, handles webshell connections, and assigns tasks to the implant, while the model analyzes the results and decides what to do next.
The key takeaway is that the introduction of AI into the attack chain does not yet present fundamentally new challenges for detection. All the “intelligent” work remains on the attacker’s side, while the compromised host is subjected to familiar actions: from reconnaissance via Kerberoasting and AS-REP Roasting to LSASS dumps, DCSync, and the Golden Ticket attacks. This is a typical, well-documented set of domain compromise techniques. The novelty of the attack lies not in the methods themselves, but in the speed and ease with which they were executed: AI orchestration has lowered the skill requirements for the operator, but has not taken the attack beyond what defenders already know and are capable of detecting. The timing is also telling: individual key phases of the activity (such as establishing a foothold, lateral movement, and obtaining credentials) took only a few hours, and the entire attack – from agent deployment to the compromise of domain administrators – was completed within 3–4 days.
However, the CyberStrikeAI architecture does not limit users to the scenario described. The same mechanisms allow for the on-demand assembly of more complex chains – including DPAPI secret extraction and attacks on SCCM and Azure IMDS – all of which are within reach of the same group of actors, with a relatively low skill barrier. As the models evolve, the gap between the complexity of orchestration and the level of techniques used will narrow, and the operator’s role will gradually shift from setting tasks to monitoring the model’s actions.
Detection by Kaspersky solutions
It may seem that attacks using AI agents require the creation of fundamentally new detection rules. Indeed, to detect the activity of an LLM agent installed on a host within the infrastructure, it is necessary to create detection logic based on the specific characteristics of the agents. Detection rules for this activity can be found using Hunt Hub with the following filter.
However, in the case of the attack described, a different logic applies. The main difference lies in the architecture of the attack itself: the LLM agent was not located within the corporate network perimeter. It operated remotely via a C2 agent, orchestrating actions, and left no traces of its presence in the infrastructure (such as specific API requests to local LLMs or anomalous patterns of resource consumption by hosts).
The key difference between this activity and an attack by an experienced human operator lies largely in speed. Tactically, technically, and methodologically, AI, for the most part, uses exactly the same tools, utilities, and techniques as a human penetration tester. It does not write unique exploits from scratch, but rather combines known methods and dynamically adapts them to the situation, handling the tools’ errors on its own.
Since the actions performed by an AI agent on the network are indistinguishable from those of a human, classic, well-tuned correlation and behavioral analysis rules are sufficient to detect it. Here are a few examples of how Kaspersky Next EDR Expert successfully detects the attack described:
During the attack, the adversary will need access to the victim’s credentials; in the described case, one way to obtain them was through a well-known technique that uses legitimate tools to dump LSASS, specifically by calling the MiniDump function from comsvcs.dll. The EDR Expert solution detects this activity using the rules dumping_memory_with_com_services_dll and suspicious_lsass_memory_access.
A significant part of the attack chain is lateral movement, which helps the attacker navigate within the infrastructure and achieve their desired objectives. In the described case, the WinRM protocol is used to initiate connections directly from PowerShell. This is a standard technique that allows the attacker to execute commands on remote machines without using additional network tunnels. The EDR Expert solution detects this activity using the rules using_powershell_for_remote_execution_via_wmi and winrm_send_command.
Kaspersky Anti Targeted Attack (KATA) is used to detect malicious activity in network traffic. Communication between CyberStrikeAI agents and the command-and-control server occurs without accessing AI platforms such as ChatGPT or Claude. Instead, the agent’s C2 server is an infrastructure pre-configured by the attackers, just as in attacks that do not use AI agents. Analysis of decrypted network traffic using NDR-class solutions reveals characteristic communication patterns of CyberStrikeAI agent activity. When these patterns are detected, KATA generates an alert with the verdict Backdoor.CyberStrikeAI.HTTP.C&C.
Alert regarding the detection of CyberStrikeAI communication with a C2 server
To detect post-exploitation activity, you can use not only IDS technology but also NAD (Network Anomaly Detection). It analyzes all traffic for suspicious indicators that do not correspond to a node’s typical network activity.
For example, actions performed by CyberStrikeAI during the Domain Discovery phase are detected by an NDR:NAD rule named “Scanning domain records via LDAP queries.”
NDR:NAD alert: reconnaissance via LDAP queries detected
You can learn more about NDR:NAD technology in our article on Securelist.
You can also visualize the connections between C2 addresses and files used by attackers in the Research Graph section of the Kaspersky Threat Intelligence Portal. This includes tracking the emergence of new CyberStrikeAI implants that communicate with malicious addresses.
Visualization via the Research Graph on the Kaspersky Threat Intelligence Portal
In addition, the Threat Lookup service available on the portal allows you to determine whether malicious files belong to CyberStrikeAI using attribution mechanisms based on the executable file’s code.
Demonstration of attributing a malicious implant to the CyberStrikeAI framework
Kaspersky SIEM detects all stages of an attack by the CyberStrikeAI agent. The product repository contains over 100 rules for detecting the techniques discussed in this article; we will list the most critical ones below.
Execution of various commands from the sqlservr.exe process:
R300_04_Windows shell started by a web application
Downloading and executing a payload via PowerShell:
R110_03_PowerShell code downloaded and executed
Creating Windows scheduled tasks:
R099_04_Suspicious arguments when running schtasks.exe
R300_03_Windows shell started by the scheduler
Persisting via crontab or bashrc:
R099_06_Suspicious cron job activity
R405_02_UNIX shell configuration modification
Rules located at the KUMA Packages/SOC package/Configuration discovery path detect the collection of information about hosts, network settings, and domains using various reconnaissance tools. Rules that aggregate detections by reconnaissance tools:
R224_14_Windows reconnaissance activity
R224_09_System information discovery by running multiple utilities within a short period
R224_04_System information discovery via standard Linux tools
Data collection for Kerberoasting and AS-REP Roasting:
A modern organization protects its information systems with a whole suite of technologies that generate thousands of security alerts every day. Looking at these alerts in bulk, you’ll see that a significant share are false positives. Ideally, these alerts would be filtered out automatically so that analysts could focus on the ones that may point to a real incident. However, writing filters is a time-consuming task in itself. To create a correct filter, an analyst needs to:
Review the logs
Identify the source of the activity
Define filtering boundaries
Choose filtering criteria
Write a rule
Check that the filter is robust
This post looks at how filter creation itself can be automated to reduce analyst workload.
Filter validity criteria
In the context of security alerts, a filter is a combination of event field values that marks a detection as a false positive and not worth the analyst’s attention. Filters can be generated for any combination of event fields, but not every combination yields a valid filter. That’s why we need to define validity criteria: conditions showing that a specific filter actually removes noise and doesn’t suppress useful alerts.
Detection rules in security systems typically contain a set of conditions, and each of them can generate an alert. A specific event triggers a given fragment of a detection rule. The set of events that a given fragment responds to is what we’ll call its context. A good filter should cover the entire context where possible, without going beyond it. Filters that are too broad or too narrow are useless. For example, a filter based solely on PowerShell would exclude too many events, including some that deserve the analyst’s attention. Most of the filtered events would also be unrelated to the rule in question. A filter on a specific ID, on the other hand, would cover only one event, which may never recur.
Problems in filter generation
We can run into a number of problems when creating filters. First, events often contain an excessive number of fields (around 400 on average), and most of them aren’t needed for filtering. At the same time, generating and ranking combinations of these fields is also fairly resource-intensive. So, the first step is to discard the irrelevant fields and keep only those worth using in the filter. For example, out of 400 fields in an event, four may be enough for filtering.
Another problem is string normalization. Field values (for example, the path to the same application on different systems) can vary depending on system settings, user folder names, and so on. For a filter to account for all these variations, the strings must be normalized. For file paths, in particular, you can replace the drive letter and user folders with standard environment variables and convert all paths to a single case.
Finally, if a filter completely mirrors the query of a detection rule, it effectively disables that rule. To fix this, remove the event fields used in the detection rule from the filter. For example, if a rule triggers on a file path, there are two ways to filter out unwanted alerts:
In the filter, use fields other than the file path.
Use a part of the file path that the rule doesn’t use. For example, for the rule file_path: ".../something.exe", you can set up a filter that excludes events with the user/unique_files/ directory in the file path.
Filtering security alerts with an algorithm
Given the problems described above, automatically generating filters for security alerts should consist of the following steps:
An analyst receives a security alert that they assess as a false positive and uses the filter generator.
The generator takes the 400-field event from the alert, along with the rule that triggered on it, and determines the context.
The generator selects the fields that are relevant to the filter.
The generator normalizes the strings.
The generator builds different combinations of the selected fields. To do this, we applied the FP-Growth (frequent pattern growth) algorithm to the context determined earlier. FP Growth builds a tree of frequently occurring items (fields) from a dataset (in our case, the context) and discards items that aren’t frequent enough. This reduces the number of combinations to check, which lowers the cost of finding the most relevant ones.
The generator ranks the resulting combinations and offers the analyst the top three to choose from.
For example, consider an event described by the following JSON:
After generating and ranking the combinations, we got three filters based on file paths:
processcmdline:("nodejs\\node.exe" AND "*****\\appdata\\roaming\\npm\/node_modules\/pi-coding-agent\/dist\/cli.js")
file_path:"*****/.pi\\agent\\bin\\fd.exe"
processcmdline: "programfiles\\nodejs\\node.exe"
The last filter turned out to be too broad, but the analyst marked the other two as valid.
Pros and cons of the algorithmic approach
The algorithmic approach to filter generation has several advantages. First, it’s simple and deterministic: the same alert always produces the same result. Second, it’s interpretable, meaning we can see why a given combination ranked near the top of the list and why a particular field didn’t make it into the list of candidate fields at all. Third, the stages of the process are independent of each other, so individual steps can be improved and tuned without the risk of breaking the algorithm elsewhere. Finally, it has no external dependencies or models, which makes it easy to deploy in any customer environment.
However, it also has drawbacks. The first is its dependence on context. If there’s no context for some reason — for example, the rule’s first-ever trigger — a filter can’t be created. The second problem is string normalization. There’s a high chance of running into atypical cases that the normalization rules don’t cover. Often such cases can’t be described correctly at all, because they contradict each other.
These problems can be solved with large language models (LLMs). When an LLM generates the filters, no context is needed, because the LLM doesn’t iterate over or rank combinations. The LLM also takes a more flexible approach to string normalization, including non-standard cases. That said, an LLM doesn’t have to be involved at every stage of the generation process. We decided to keep the algorithmic solution where it works well. For example, a simple algorithm selects suitable fields without errors, so we didn’t move this stage to the model.
Filter generation with an LLM
The LLM-based filter generation looks like this:
The input is still an alert containing an event with 400 fields, plus the rule that triggered on that event. Then an algorithm selects the most suitable fields for the filter. Next, the LLM processes the input — the event, the selected fields, and the detection rule — and generates three filter options along with an explanation for them. The explanation helps the analyst understand why these particular filters were suggested and make an informed choice.
Consider the following event in JSON format:
The LLM suggested three filter options that all contain the same command line fragment:
file_path: "\\WindowsPowerShell\\powershell.exe" AND filecmdline: "Get-VM -Name kafka\*"
filecmdline: "Get-VM -Name kafka\*"
filecmdline: "kafka*"
As in the previous example, two of the three output filters were valid. The last one was too broad to be usable. The analyst chose the first filter with minor edits:
file_path: "powershell.exe" AND filecmdline: "Get-VM -Name kafka\*"
Pros and cons of generating filters with an LLM
Using an LLM solved the problems of purely algorithmic filter generation: dependence on context and errors in string normalization. However, the single-request approach had its own drawbacks. First, it had no output validation. The LLM returned filters as-is, with no syntax check and no way to correct errors. Second, unlike in the algorithmic version, all filter generation tasks were handled by a single system prompt. As a result, a minor fix in one place could break the logic in another.
Using multiple AI agents
To address the problems of generating filters with a single model and a single system prompt, we tried distributing the tasks across different LLM agents. In this version, we brought in agents as early as the stage of selecting relevant fields. The chain includes four agents in total:
Selector: selects the relevant fields.
Generator: generates filters.
Validator: evaluates the generated filters. If the filters are found to be invalid, it returns the task to the generator. If the selected fields are found to be irrelevant, it starts a new field selection cycle. If the filters pass validation, or the limit on regeneration attempts is reached, the valid filters (or the best ones available) are passed to the analyst.
Commentator: analyzes the output filters and explains which field values were used and why.
For the following JSON event, the agents produce three valid filters based on the file path.
The filters differ in the additional parameters that support the detection:
file_path:"sysvol\\domain\\scripts\\logon.bat"
file_path:"sysvol\\domain\\scripts\\logon.bat" AND file_md5:"0x7..6E"
autorun_entry: "Group Policy\\State" AND file_path: "SYSVOL\\domain\\scripts\\logon.bat"
Pros and cons of the agent-based approach
LLM agents give us a system that can validate and correct filters. Its modular architecture also lets us tune and improve different stages of generation independently. However, this approach makes more LLM calls than the previous ones, so the system is slower. It also depends on access to a model, which may not be available in the organization’s isolated environment.
Evaluating the filter generation system
To evaluate how well the filter generation system works, we use two main metrics:
Approval rate. For each security alert, the system suggests three filters. If the analyst selects at least one of them, we count the generation as successful. For example, in the case below, the approval rate is 2/3.
False positive reduction rate (FP drop). This metric shows how much a filter helps reduce the number of false positives. It can only be measured over time, because we need to compare the number of false positive alerts received during a set period before and after the filter is deployed.
Below is a comparison of the three filter generation approaches by these metrics:
As the results show, LLMs significantly improve the efficiency of filter generation. At the same time, the LLM agentless and agent-based approaches perform almost identically. So we chose the simpler and faster option: an LLM with a single system prompt. As a result, we cut false positives by 99%, increased the number of filters generated per day by 28%, and made analysts’ alert handling 17% more efficient.
Takeaways
Practice has shown that filter generation can be automated effectively. We’ve looked at several options for automatically generating filters for false-positive security alerts: a purely algorithmic approach, an LLM-based approach, and an approach built on a group of LLM agents. All of them can generate valid filters and make the analyst’s work much easier, but each has its own pros and cons.
The algorithmic approach scored lower on the evaluation metrics, but in two-thirds of cases, it still produces filters that satisfy the analyst. It works especially well when there’s already a set of similar events to filter out, meaning enough context has accumulated. The algorithmic generator can also be deployed in any environment. Both standalone LLM and multi-agent LLM approaches show high accuracy, and their results differ only slightly, so the slower agent-based approach looks excessive at this stage. If an LLM is available, the best option appears to be a single model that handles several stages of the generation cycle.
Fraud prevention combines rules, AI and behavioral analytics to stop scams, reduce false declines and keep automated decisions explainable through human review.
Most enterprise data was designed to be consumed by people. But automation and AI agents will soon make up a much larger share of the workforce. KPMG’s Global Tech Report predicts that digital assistants will account for 36% of core technology teams’ capacity by 2027, up from 28% in 2025.
This is why data readiness has risen to the top of technology leaders’ priority lists. In a separate KPMG survey, 58% of leaders cited data readiness and access as one of their biggest challenges to deploying AI agents.
Data that works for reports and dashboards can create problems for AI. Definitions may differ across the business, with data stored separately from the rules governing its use.
Preparing for an AI workforce starts with making enterprise data searchable, contextual, and trusted.
Three steps to AI-ready data
1. Make enterprise data searchable.
AI agents need to identify which data to use and where to find it across multiple data products and technology environments.
An ontology maps business concepts to the data associated with them. When an agent receives a question or action, it breaks the request into relevant domains and concepts. The ontology then identifies which data products and assets contain the information it needs.
Consider a wealth advisor asking an AI assistant about a customer’s recent branch interactions to identify potential cross-sell opportunities. Answering might require pulling product data from one data platform and branch experience data from another entirely.
2. Give AI the context it needs.
AI also needs to understand what enterprise data means. Let’s say you ask AI: “What’s our best-selling product in the mid-market segment?” The answer hinges on how the business defines “best-selling” – by units, revenue, or margin – and which accounts qualify as “mid-market.”
Knowledge engineering captures and makes this organizational context available to AI. It does this through:
technical metadata: identifies what data exists and how it flows through systems
semantics: define business terms, definitions, and synonyms
ontologies: establish relationships among business concepts
knowledge graphs: connect those relationships to enterprise information
These elements help AI interpret data using the same business meaning employees apply to it. Knowledge engineering can also incorporate institutional knowledge that agents can draw on when making autonomous decisions.
3. Build trust into AI-ready data.
AI agents need to make decisions from authoritative, governed data. Existing data controls provide a good starting point.
Enterprises also need to determine whether an agent inherits the access privileges of the person using it or receives its own permissions. Those guardrails govern what information an agent can use when making a decision.
Finally, governance should extend to the contextual layer, with clear ownership of the definitions, relationships, and business rules that determine how agents interpret information. These rules create a traceable path from source to context, making decisions easier to explain and validate.
AI readiness starts today
Making enterprise data AI-ready is a no-regret investment, as long as the work is tied to business value. AI can help accelerate that work. What delivers value today can also prepare the business for more advanced AI capabilities in the future.
Innovation is about balancing control with autonomy. But when a “perfect prototype” developed with high autonomy meets the reality of enterprise-wide deployment, many organizations find themselves unprepared for the complexities of scaling.
According to KPMG’s 2026 Global Tech Report, roughly 60% of organizations say AI investment is outpacing their governance capabilities.
Enterprise AI puts new demands on IT operations. As AI takes on a larger role, CIOs need the structures to govern and manage it over time. An IT maturity assessment can help CIOs prioritize the investments and improvements needed to support their AI goals.
The IT maturity gap behind AI
AI can move quickly with a prototype because teams tightly control where and how it operates. In full-scale production, AI has to work within the parameters of existing technology and processes, including legacy systems, architecture constraints, and security requirements.
For example, one KPMG LLP insurance client found that its underwriting AI team had to develop enterprise architecture rules as it tried to move its solutions into production. As you might expect, those rules were overwritten when they went to scale. This leads to what can be called the “perfect prototype problem.” A team becomes anchored to a solution that works perfectly in isolation but resists the necessary controls required to scale.
Further, without clear ownership and lifecycle management, organizations risk growing a population of “AI dark zombies” that cost money, drift from their original intent, go unsupported by the help desk, and never properly shut down. This army of dark AI will create significant technical debt and risk.
Once deployed, AI needs clear ownership, so it remains supported and useful as technology and business needs change. IT also needs visibility into what AI is running across the organization so teams can manage those investments and retire deployments that no longer serve a purpose.
What AI readiness requires from IT
An IT maturity assessment shows how well current IT capabilities can support AI and identify the areas that need attention.
AI readiness depends on several core IT capabilities:
Enterprise architecture (EA): AI leaders have a 44-point maturity gap over laggards in enterprise architecture, highlighting how critical this “revenge of the EA” is for success.
Strategy and investment management: Use value architecture to assess AI investments and determine what’s worth pursuing.
Asset management: Manage AI as an enterprise asset, optimizing costs and managing it throughout its lifecycle.
Governance and risk: Define how much autonomy AI should have and where human oversight is needed.
Data management: KPMG research shows that AI leaders are 2.5 times more likely to have mastered their data, often through the use of certified data products that can be trusted across the organization.
With strength in these capabilities, teams can take new approaches with AI more quickly because the structures needed to support them are already established.
Build trust before adding autonomy
Trust in an AI system, much like trust between humans, relies on four fundamental behaviors:
credibility
reliability
transparency
cooperation
Within KPMG’s Trusted AI framework, these behaviors are operationalized across 10 ethical pillars, such as explainability, data integrity, and accountability. This ensures that systems remain values-driven and human-centric as autonomy scales.
It also requires fine-tuning the enterprise risk framework specifically for AI by identifying new threat vectors, assessing their likelihood and impact, and defining mitigations. AI is sharing more “first line of defense” responsibility with humans, so organizations must negotiate and monitor expectations when the “line” is not human.
Unlike with most human decisions, an AI system’s decisions can be systematically inspected. Under a mature Trusted AI model, transparency and explainability eliminate the black box by validating data integrity upfront. This model also provides traceable decision logic that allows CIOs to verify whether stated behavior matches actual execution.
Scale AI without losing sight of it
For AI to take on more responsibility, CIOs need to decide where it can act independently and where human oversight is warranted based on risk. IT also needs ongoing monitoring to make sure AI continues to perform as intended and stays within boundaries.
These data and controls give CIOs greater confidence to extend AI into higher-value use cases while protecting the business from operational and reputational risk.
See how the KPMG IT Maturity Assessment can help you prioritize the IT improvements needed to expand AI across your enterprise.
Most translation models are primarily trained for high-resource Asian and European languages. Most African languages, spoken by hundreds of millions of people, are relatively neglected, compared to their high-resource counterparts.
Although AI underinvestment across the African continent has created a significant barrier to adoption among citizens, AI could generate $1.2 trillion for Africa’s economy by 2030, equivalent to 6% of its GDP, according to a UNESCO report.
Existing open-source LLMs underperform on African machine translation, and the shortage of large-scale, high-quality, open-source parallel data has constrained the development of competitive small language models in this space.
Tether’s AI Research group has developed TranslatePsy-AfriSLM to narrow this digital divide and lower the barrier to entry for AI adoption across the continent. TranslatePsy-AfriSLM is a collection of open-source machine translation models that outperform bigger systems like Google’s TranslateGemma-27B and Alibaba’s Qwen3.5-122B-A10B.
Inclusive linguistic AI tools for Africa
Africa’s linguistic diversity, paired with the world’s fastest-growing youth population – 70% of sub-Saharan Africa under thirty– is a key indicator of the potential for high-impact AI.
But while AI tools evolve and proliferate across high-income countries, only one African country (South Africa) scores higher than 50 out of 100 in AI infrastructure on the 2025 Government AI Readiness Index by Oxford Insights.
Several recent AI initiatives have promised to tackle the AI disparity in Africa; for example, Google’s AI policy blueprint for Africa, which lays out how African nations can harness AI for economic growth. Nonetheless, when it comes to specific, foundational, and immediately transformational tools, rather than long-term policy promises, open-source AI is most useful, particularly when it comes to African languages.
Unfortunately, most frontier open-source models underperform on languages other than English. Most frontier AI models work well in a handful of languages, and poorly in the rest. Smaller, more efficient models are useful to tackle the widening skills gap.
Healthcare is one of the highest-impact applications. This is due to the variety of many different local languages and the fact that connectivity can be unreliable in the communities that need information most.
Combined with Tether QVAC MedPsy, a small foundation model for medical and healthcare applications, TranslatePsy-AfriSLM creates a potential pathway to deliver medical knowledge and health education in the local languages of hundreds of millions of people.
Agriculture, humanitarian response, and cross-border communication
The potential for agriculture is also huge. Local translation could allow farmers to get agricultural information in their own language. In humanitarian and disaster-response settings (which often lack reliable connectivity), offline translation can support coordination on the ground without needing a network connection.
Tether’s solar-powered kiosks across Sub-Saharan Africa let residents charge a phone, swap a battery, and access digital financial services where the grid and the banking system don’t reach.
For NGOs and field organizations, local-language translation would allow field workers to communicate across multiple communities without having to carry separate translation systems.
Breakthrough performance without cloud dependence
Tether’s researchers were able to achieve stronger translation performance with significantly smaller models, all without cloud dependence.
Tether’s multilingual models are fully open source. Any developer can download them directly from Hugging Face and integrate on-device translation into their own applications, rather than relying on cloud APIs or requiring users to switch to a standalone translation app.
As translation takes place directly on the user’s hardware, the models can be integrated into applications without relying on proprietary cloud APIs or transmitting sensitive text to external providers.
The smallest TranslatePsy-AfriSLM model has just 800 million parameters, yet it outperformed Qwen3.5-122B-A10B, TranslateGemma-27B, and NLLB-3.3B across three separate benchmarks.
TranslatePsy-AfriSLM covers 19 Sub-Saharan African languages including Hausa, Amharic, Yoruba, Lingala, Swahili, Igbo, Zulu, Somali, Oromo, Malagasy, Kinyarwanda, Xhosa, Afrikaans, Wolof, Luganda, Nyanja, Shona, Tswana, and Southern Sotho.
Tether’s European language models
TranslatePsy-AfriSLM is being released alongside Tether’s European language models, TranslatePsy-EuroNano. These models are small enough to run efficiently on edge devices while supporting nine European languages from a single multilingual deployment, making multilingual experiences practical for a much wider range of software.
At its smallest tier, Tether’s deployment is 17.6 times smaller while maintaining comparable translation quality.
Alongside its research into open-source language models that provide access to frontier AI capacity, Tether is building on its mission to ensure that data stays with the user with QVAC, a local AI that keeps your data on your device. QVAC is also free to run with no per-token or per-use cost.
Africa’s AI economy reaching $1.2 trillion by 2030 depends on how readily available access is to tools that people need, in languages they actually speak. Open-source models that run on people’s phones and laptops help narrow this gap by providing infrastructure that developers can build on, and technology that people can use.
TranslatePsy-EuroNano and TranslatePsy-AfriSLM are available through QVAC SDK for integration across Android, iOS, Linux, macOS, and Windows, and for download on Hugging Face at this link.
Every IT leader knows the pattern. One team builds a report in a spreadsheet. Another spins up a workflow with slightly different logic to answer the same question. A dashboard is shared across three departments, and within a week, nobody can say for certain where the underlying numbers came from.
Instead of freeing up capacity, self-service has quietly become another form of manual work: chasing down mystery logic, reconciling duplicated effort, and answering questions nobody wants to own.
Self-service was never the risk
It is tempting to read that scenario as an argument for tighter control — fewer people building, more requests routed through a central team, more approvals before anything ships. That reaction is understandable, but it solves the wrong problem.
Self-service fails when there are no shared rules for access, quality, documentation, and ownership. Without those guardrails, speed doesn’t produce faster decisions, just more confusion distributed across spreadsheets and more shared drives.
The real tension is that most organizations have been offered only two options. Either lock everything down, or let everyone build whatever they want and hope it holds together. Neither one scales.
IT as the paved road, not the checkpoint
Centralizing data was never the hard part. The real challenge is the last mile: turning that data into decisions and actions the business can actually trust. Closing that gap does not mean IT owns every rule, calculation, and exception that determines how work gets done.
It means IT builds the paved road — trusted access, approved workflows, reusable templates, and visibility into what is being built — while the people closest to the work own and adapt the business logic that runs through it.
That division of labor changes what “governance” means in practice. Instead of a gate every request has to pass through one at a time, governance becomes the infrastructure that keeps logic visible, understandable, repeatable, and auditable by design. When the fastest way to answer a question is also the most trusted way, analysts do not need to be talked into compliance, and IT does not need to inspect every workflow to know it will hold up. It is simply how the work gets done.
Freedom and guardrails, together
Governed self-service isn’t about choosing between speed and control, it’s about giving each side of the equation what it actually needs to trust the other.
Governed self-service gives analysts:
Access to trusted data
Reusable templates and workflow patterns
Clear rules for sharing and automation
A way to document logic
Support when a workflow needs to scale
And it gives IT:
Visibility into who is building what
Better governance over access and data use
Fewer one-off requests
Less mystery logic floating around the business
A cleaner path from individual workflow to team-wide process
What this looks like in practice
Papa Johns’ finance team offers a useful example of governed self-service in action. The team handles risk-sensitive, high-volume work — franchise billing, royalty calculations, aggregator commissions, and SOX-compliant period close — across a global, multi-currency franchise business.
Historically, much of that logic lived in spreadsheets and disconnected tools, separate from the systems of record and hard to audit when workflows changed.
Using Alteryx, Papa Johns rebuilt franchise billing and reconciliation as a governed workflow that runs directly against its Google BigQuery environment, so calculations execute where the data already lives rather than being copied out to another location.
With Alteryx, complex calculations are visible, repeatable, and auditable. Finance users can ask natural language questions, such as comparing month-over-month figures, and receive immediate answers while also seeing how logic is applied. IT can support governance without becoming a bottleneck.
The partnership between the business and IT was key to scaling success. Michael Wyant, VP of Enterprise Data and Corporate Solutions, and his team are responsible for governance and data pipelines. The finance team owns the business logic and can adapt it as requirements change.
Each side owns the part of the problem it understands best.
The result is a workflow that finance trusts, that IT can stand behind, and that scales as a template for other high-stakes processes across the business. That’s the kind of outcome that governed self-service is meant to produce.
Fewer surprises, more trust
None of this requires IT to slow analysts down or analysts to work around IT. When self-service is built on shared standards, analysts stop waiting on tickets, IT stops chasing down mystery logic, and the business gets answers that hold up the moment someone asks, “Where did this number come from?”
Alteryx supports that model by giving business teams a governed way to build and adapt workflows themselves, while giving IT the visibility, controls, and security required to support it all at enterprise scale.
The goal was never more control for control’s sake. It is fewer surprises, less rework, and more answers the business can actually trust.
Ready to see what governed self-service could look like for your team? Explore the AI-Ready Starter Kits to get started.
There’s a scenario that plays out every day across the enterprise. A salesperson is about to close a major deal. They want to know what their commission will be. They type the question into ChatGPT or their favorite AI assistant. What comes back is a thoughtful, well-written explanation of how software companies typically structure sales compensation.
The one thing it won’t tell them is what their commission will actually be if they close this specific deal. That gap between what AI can reason over and what it knows about your business is the defining challenge of enterprise AI adoption right now.
I call it the logic layer. And without it, AI gives you impressive sounding outputs that are often disconnected from how your business runs.
Why business logic lives with the analyst
One of the more persistent myths in AI is that analysts are on the verge of becoming unnecessary.
The reality is the opposite, and the logic layer is exactly why.
In an AI-enabled enterprise, analysts become more essential because they are closest to the logic and context that governs the business. They know which definition of pipeline matters and which edge cases matter in audit, merchandising, finance, or marketing.
I believe enterprises that succeed in the AI era will not be defined by how much AI they deploy but whether the people who understand the business own and control the intelligence that runs it.
If that ownership defaults entirely to IT or to a vendor’s black box, companies risk scaling systems they cannot fully adapt or audit. Giving business teams the tools and mandate to own their logic is what makes the AI system trustworthy and responsive to how your business runs.
That is why I see analysts as the architects of this next phase.
What the logic layer looks like in practice
Let me return to the commissions example, because it illustrates the concept precisely. Right now, when a salesperson needs to know their commission on a deal, they send a message to the commissions analyst. That analyst has their own spreadsheet — because comp plans change every quarter, with spiffs and special programs layered on top. They run the math manually and send back an answer.
What if that same analyst built a simple, well-defined calculator that encoded their commission logic — the actual rules for your company, your plans, your programs — and connected it to the AI systems your salespeople are already using? Now when a rep asks what their commission will be on a specific deal, they get the right answer. Not a generic explanation of how commissions work.
And here’s the compounding value: that same logic can then be used by the annual planning agent to model the operational cost implications of different comp plans. It can feed the scenario planning model that runs hundreds of simulations for financial planning. The analyst who built it enables an entire network of AI systems to act on accurate, business-specific logic.
That’s the logic layer in practice: curated, purpose-built data assets and calculators that encapsulate how your business works, maintained by the people who understand it, deployable to every AI system that needs it.
What the logic layer requires
This is where I think most companies are still stuck. They’ve made the infrastructure investments. They have cloud data platforms and approved LLMs. But they’re asking those systems to do things they were never designed to do on their own.
The logic layer requires three things:
Purpose-built data assets. A narrow, clean, well-defined data set that reflects how you actually measure a specific business process.
Encoded business logic. This is the part that lives in people’s heads right now — the policies, the edge cases, the context that makes data mean something.
The ability to update it. Nobody runs a business to keep it the same. The logic layer has to be something that domain experts can update when the business changes.
A pragmatic path forward
The good news is that you don’t have to wait for a perfect architecture before you start building a logic layer.
Start with your highest-value, most-repeated business processes — the ones where an analyst is currently fielding the same questions week after week. These are the processes where encoding logic into a curated, AI-ready data asset delivers immediate, measurable value.
Then, empower your analysts to own that encoding — not IT. Give them low-code tools to do the work, and the mandate to treat that encoded logic as a strategic asset they own and evolve as the business changes.
This is also where leadership posture matters.
I have said for a while that this should not be framed as a choice between business and IT. It is both. IT should set standards, manage infrastructure, establish security boundaries, and make approved AI capabilities available across the organization. But IT should not become the bottleneck for every piece of business logic the company needs to operationalize.
If this feels familiar, it should. We have seen this pattern before in enterprise technology. Infrastructure and platforms matter. But the last mile, the part that turns capability into business value, always depends on the people closest to the work.
AI is no different.
The companies that get the most from AI will be the ones that treat it like an operating model. They will automate core workflows, curate the right data, and empower analysts and domain experts to define the logic that makes AI useful and generate answers the business can use.
I recently had a chance to go deeper on these ideas on the Talking AI podcast. If you want to hear more of my thinking on the analyst’s evolving role, how the logic layer connects to agentic workflows, and why I think the next 18 months will be pivotal for getting this right, it’s worth a listen.
Every new frontier model release seems to spur a fresh round of doomsday articles. Just Google “the end of white-collar jobs,” and you’ll be bombarded with discourse on the end of modern work, the unraveling of the social contract between employees and organizations.
What I don’t see anyone talking about, however, and what I believe is a far more productive conversation, is the opportunity for knowledge workers.
Nobody understands critical business processes better than your line-of-business (LOB) employees. Not executives. Not IT. Not even the most advanced LLMs. These are your business analysts and RevOps professionals, your supply chain managers and finance leaders, and the employees whose expertise has been forged over decades.
For an enterprise to become truly intelligent, these workers must be involved in how AI workflows are built and deployed. Their guiding hand is the only way AI can learn and truly understand your business.
But what does this transition look like, and how can organizations start operationalizing AI in a meaningful way alongside knowledge workers? Let’s take a look.
What enterprise intelligence requires
Imagine walking your board through a set of financials and recommending specific actions. Then, in your next meeting, you walk everything back because your AI layer got the numbers wrong.
There is no faster way to kill an AI initiative than by delivering wrong outputs. Without trust, the whole system falls apart.
In our recent survey of 1,400 business and IT leaders, we found that while over 90% of organizations are using AI, only 28% trust it to support decision-making. As for how many organizations scaled their AI pilots into production, the number was just under 25%, suggesting a very strong correlation between trust and operationalization.
An intelligent enterprise, then, is an organization that has trustworthy AI embedded across the business.
At Alteryx, we say the results of any AI system must follow our VURA framework: an AI system and its outputs must be visible, understandable, repeatable, and auditable. In other words, two people need to be able to go to AI with a question and arrive at the same answer; anyone who uses AI in their workflows must be able to explain how their AI system arrived at that answer.
Who’s responsible for operationalizing AI?
Enterprise intelligence is about trustworthy AI deployed throughout key business processes, but who’s ultimately responsible for these AI systems and processes: IT teams or knowledge workers?
Let’s say you want to use AI in your Sarbanes-Oxley process, e.g., your journal entries, revenue recognition, access controls, etc. Before IT can help you build a new AI workflow, IT must first understand your Sarbanes-Oxley process in great detail. Then, they have to code a tool your finance team can trust.
It’s possible, sure. But creating this solution would take an inordinate amount of time. Then, when a new regulation comes along or you have an acquisition, the whole thing falls apart. You have to get back in line with IT to retune everything.
Moreover, if your books don’t balance out or if you fall out of compliance, IT does not want to have that responsibility fall on them. You can see why ownership of AI systems and workflows must sit with LOB workers. They are the only ones with the expertise to ensure the veracity of AI’s outputs. They are the only ones who can successfully shape and define its logic and oversee its ongoing execution.
Data is the fuel. Business logic is what keeps AI on course.
Finally, there’s the question of data. We’ve all heard “bad inputs, bad outputs.” Seeing as I’m the CEO of a data analytics company, you might expect me to say that reliable data is the end-all, be-all when it comes to trustworthy AI outputs.
And while it’s absolutely essential, it’s only the first step.
Aggregating your enterprise data into a cloud data platform is immensely useful. All of that data becomes readily accessible. You gain a single source of truth across teams and workflows. But you can’t point your LLM at a cloud data platform and ask it to make sense of your data for a complex business process.
Again, you need the people who understand these critical processes to guide your LLMs to interpret the right data in the right way. This is what will make your AI systems visible, understandable, repeatable, and auditable. Yes, you need clean, reliable data. But more than that, you need business logic around that data, and that can only come from your knowledge workers.
The five pillars of enterprise intelligence
At the highest level, enterprise intelligence rests on five core pillars:
Trustworthy, transparent data
Empowered business analysts
Shared responsibility across the C-suite
Cross-functional collaboration
Leadership that evolves alongside AI
Each pillar reinforces the same core idea: AI only becomes valuable when it’s grounded in reliable data, shaped by real business expertise, supported by executive ownership, and scaled across teams that can put it to work to improve their daily processes.
Tap into the intelligence all around you
As a business leader looking to build an intelligent enterprise, the most important questions you can ask are the ones around operationalizing AI in key business processes. What would it take for you to trust AI’s outputs? What would make AI-powered processes superior to your current ones?
Once you have those answers, engage your LOB workers immediately. Give them ownership and autonomy. Rather than asking AI to replace them, lean into their intelligence. Let your knowledge workers use their expertise to amplify, shape, and govern AI. Their business mastery is what makes enterprise intelligence possible.
Have you ever read these words during an AI workflow? Nothing kills trust faster than incorrect outputs. It’s no wonder, then, that only a quarter of businesses today fully trust AI to support decision-making and forecasting.
And yet, we know AI is business critical. Nine out of 10 businesses are using it; 64% say it’s powering innovation.
So, how do you bridge the gap from experimentation to trustworthy deployment? How do you get verifiable, reproducible results from AI at scale? In this article, I’ll show you the framework that’s powering AI success for leading organizations.
Why organizations still don’t trust AI
We asked 1,400 IT and business leaders what their biggest barriers to success with AI workflows were. One in two (49%) said inaccurate or biased outputs; 38% said it was a reluctance to allow AI to make decisions without human oversight.
Then, there was the data issue. Data readiness is an integral part of successful AI workflows. However, half of all organizations said they still faced poor quality or fragmented data. While you don’t need perfect data to start using LLMs, you absolutely need trustworthy data.
VURA: The framework for trustworthy AI
Closing this trust gap requires two things. First, organizations need a logic layer that connects AI systems to the people who understand the data and business best. Line-of-business teams and analysts cannot sit on the sidelines. They need to help build and validate AI workflows so the logic behind AI’s outputs reflects how the business actually operates.
Second, AI workflows and processes should be visible, understandable, repeatable, and auditable. Together, these principles form VURA, a framework we developed to help organizations build and scale trustworthy AI systems. These guidelines will help build trust in your data and your AI’s outputs. You’ll need both if you want your business to build enterprise intelligence. What follows are the four pillars of VURA.
Visible
Visibility is transparency. Your AI workflows shouldn’t be a black box regarding the data used and the logic applied. Every employee using AI tools should be able to answer two questions: “Where did this answer come from?” and “How did we draw that conclusion?” Otherwise, employees may be working from incorrect information. They could give your customers faulty intel or make important decisions with serious downstream effects.
If those answers are still unclear, you may need to tighten your governance or reconsider whether your current AI and data solutions are working. Visibility becomes especially important when AI is used across teams.
Understandable
It can almost feel like science fiction when tools like ChatGPT or Gemini take the most complicated or vague of prompts, parse through them, and give you an intelligent, thoughtful answer.
However, this low threshold for asking and answering virtually any question in natural language isn’t an excuse for glossing over business fundamentals. Your AI systems must be able to explain the logic behind their outputs to even non-technical business users, and your business experts must be able to validate those outputs.
Repeatable
Repeatable means that with the same AI tools, data, prompts, and business logic, AI will give you the same answer every time. Two people should be able to go to AI with the same question and arrive at the same answer. If an AI system or workflow gives you an excellent answer followed by one that’s clearly wrong, it’s not ready for operationalization. You can’t trust it.
Repeatability also requires documentation. When teams identify prompts or processes that help produce reliable outcomes, those should be recorded and shared.
Auditable
An auditable AI process means you can see what happened. There’s a trail. If there’s an answer or report that seems off, you should be able to identify who owns the workflow, what data and prompts were used, what logic the system followed, and where human judgment and oversight were involved. Auditability is a check and balance for both your AI systems and the human engineers working behind the scenes.
Start building trustworthy AI systems today
AI can only deliver scalable business value when it’s grounded in trustworthy data and business logic. To operationalize these systems, you’ll have to ensure your AI workflows are visible, understandable, repeatable, and auditable.
Alteryx is the transformation and business logic layer that helps you move AI from experimental pilots to trustworthy production. It connects to data wherever it lives, helps business users apply their expertise to AI-powered workflows, and instills the guardrails needed for both your data and your AI systems.
With Alteryx, the people closest to the business can shape how data is prepared and applied, while IT gains the governance and auditability required for enterprise use. That’s how AI outcomes become trustworthy. That’s how enterprise intelligence is built.
If you’re a senior analyst, you’ve probably faced a dataset that used to open in seconds but now takes minutes. Or maybe you’re up against a formula that worked fine last quarter, but now shows an error because someone renamed a tab in a file three layers upstream. Ever spent an afternoon figuring out whose numbers are right when colleagues send back a few different “final” versions of the same report? None of that is a personal failure, but it is a sign that the volume and complexity of your work has outgrown what a spreadsheet was built to handle.
The cost is more than just your time and inconvenience. When reporting slows down, multiple versions of a number circulate before anyone catches it, or one person’s spreadsheet logic is the only process your team has for something that matters, that’s a risk to the business.
Plenty of solid analysis still belongs in a spreadsheet, but as your data and stakeholders grow, the balance between preparing data and analyzing it changes. If prep now takes more of your week than analysis does, the tool has become the bottleneck — not you.
Watch for concrete signs you’ve hit that ceiling, what a platform “built for scale” needs to do differently, and how to decide whether it’s time to move.
When spreadsheets stop being enough for your data analysis
Every spreadsheet has a hard ceiling, and it’s lower than people might expect. Microsoft’s own published specifications cap every worksheet at 1,048,576 rows by 16,384 columns, regardless of your computer’s memory or Excel version. Once a dataset crosses that line, rows don’t get flagged — they simply don’t load, and it’s easy to miss.
The bigger risk is accuracy. A 2024 literature review published in Frontiers of Computer Science, covering more than 30 years of spreadsheet research, found that 94% of spreadsheets used in business decision-making contain errors that create real risk of financial losses and operational mistakes. Most analysts already understand that the more a spreadsheet grows past its original design, the harder it gets to trust every formula in it.
Alteryx’s own research backs this up from the analyst’s side of the desk. The 2025 State of Data Analysts in the Age of AI report, a global survey of 1,400 data analysts, found that 76% still rely on spreadsheets for data preparation, even as AI tools reshape the rest of their workflow. Manual prep work isn’t a habit analysts choose, but it’s still the default because nothing else is in place yet.
Spreadsheets are ultimately designed for individual calculation, not for shared, repeatable, large-scale analysis. Asking them to do that job is where the cracks start to form, and when you need to start thinking of an alternative.
What “built for scale” means
“Scale” gets used loosely in analytics marketing, so it’s worth being specific about what a platform needs to do differently than a spreadsheet. It comes down to four tasks:
Connect to data where it already lives
A spreadsheet only knows what you paste into it, which means every report starts with an export, a download, or a copy-paste job that’s already slightly out of date by the time it’s finished. Platforms that support scale should be designed to connect, transform, and prepare AI-ready data by connecting natively to a broad range of enterprise applications, databases, and cloud platforms. This way data can be pulled in and refreshed rather than manually re-exported every reporting cycle. For an analyst, that means less time reconciling which export is current and more time on the analysis itself.
Prepare and blend without rebuilding from scratch
Scalable platforms should also give analysts a drag-and-drop canvas for cleansing, blending, and reshaping data from multiple sources, with code-friendly options like Python and SQL available for analysts who want them. It should allow for logic to be built once and held to a standard we call VURA: visible, understandable, repeatable, and auditable. Analysts shouldn’t have to deal with a chain of formulas that only one person fully understands, and that visibility matters as much as the automation. When you build a workflow as a series of documented steps, colleagues can review, troubleshoot, or take over in a way a dense formula chain rarely allows.
Automate the workflow, not just the calculation
The real definition of scale for an analyst is a process that runs without being rebuilt by hand. An essential component of that is workflow automation and orchestration so analysts can schedule and reuse any workflow they build.
Report without abandoning familiar formats
Leaving spreadsheets behind for analysis doesn’t mean stakeholders lose the outputs they’re used to. Reporting tools can generate tables, charts, and formatted outputs in PDF, HTML, or Excel, closing the loop between analysis and the people who need to read the result.
Spreadsheets vs. a scale-ready analytics platform
The differences between spreadsheets and analytics platforms are less about features and more about the needs that develop as your data and your team grow.
Consideration
Spreadsheet
Scale-ready analytics platform
Data connections
Manual export/import from each source; data goes stale as soon as it’s pasted in
Native connections to databases, cloud platforms, and enterprise apps that can refresh on demand
Repeat work
Rebuilt or copied by hand each cycle
Built once as a workflow, then reused and scheduled
Row and file limits
Fixed worksheet ceiling regardless of vendor
Designed to process large volumes without a hard row cap in the tool itself
Auditability
Hard-to-trace formulas and edits
Workflow steps that are visible, understandable, repeatable, and auditable (VURA)
Collaboration
Version conflicts, emailed copies, confusion over which file is current
Shared workspace with a single source of truth for a given workflow
Matching the platform to where your team is right now
“Scale” doesn’t mean the same thing for a 5-person team tracking budgets as it does for an enterprise running hundreds of scheduled workflows. It’s important to consider your team’s specific size and overall org structure before you shortlist any options.
If your team is still primarily working out of Excel or CSV files and wants to reduce manual, repetitive spreadsheet work, there are several platforms built just for these types of applications. Alteryx One Starter Edition, as an example, is built specifically for that transition — code-free data prep accessible from a browser, aimed at teams getting started rather than running complex automation.
You don’t need to know your exact tier or platform before you start a conversation with your team, but the conversation can go faster when you can describe your situation in terms of how many people touch the data, how often it needs to run, and who needs to see the output (rather than starting from a feature list).
Governance doesn’t disappear with spreadsheets
It’s tempting to think that moving off spreadsheets automatically solves governance, but that just changes what governance looks like. TechTarget’s coverage of data and analytics governance requirements notes that organizations should look for scalable, modular platforms that can adapt as needs change, rather than assuming governance is solved by the platform switch alone.
It’s important to investigate whether or not a platform supports this with governance and administration capabilities such as role-based access controls, audit logs, and version history. They’re built to give IT the oversight it needs while giving analysts the flexibility to build and run their own workflows.
A quick readiness check
Before you bring a platform comparison to your team or your leadership, it helps to be specific about what’s driving the need. What follows are a few questions worth answering honestly:
Are you regularly working with datasets that approach or exceed Excel’s row limit, or that make Excel noticeably slow to open and calculate? Slow-loading files and truncated imports are usually the first visible sign, not the first real cause.
How much of your week goes to gathering and cleaning data by hand, instead of analyzing it? If prep consistently outweighs analysis, that ratio is the problem — not a single unwieldy file.
If you left tomorrow, could someone else pick up your spreadsheet-based process without you walking them through it? A process that exists only in one person’s head is a significant business continuity risk.
Do stakeholders currently receive conflicting versions of the same report because multiple people are editing copies independently? That’s a flag that the workflow needs a single source of truth.
Does your organization need an audit trail for how a number was calculated, not just what the number is? Regulated or audited environments tend to outgrow spreadsheet-based tracking quickly.
If you answered yes to two or more of these, this is a reasonable signal that it’s worth having a conversation about moving beyond spreadsheets.
The fastest way to know whether a platform fits your workflow is to run your own data through it rather than a demo dataset. You can start a free trial of Alteryx One to test connectivity, data prep, and workflow automation against the kind of analysis you do every week.
The old way of creating reports is almost cliché, but only because it remains so pervasive.
It’s a familiar scene: A teammate pings you at 4:57 pm asking for a last-minute report. The data and business logic you need live across 10 spreadsheets, in five Microsoft Teams threads, and in an email from two months ago that you can’t seem to find.
But that was the old way. What happens when you use AI for the same situation?
Let’s find out.
What working with AI often looks like
Your stakeholder pings you, asking for a report based on a massive tax reconciliation spreadsheet.
This spreadsheet is a beast, chock-full of tabs, formulas, and data that’s been copied and pasted from several enterprise data sources.
“Sorry for the last-minute ask,” they say, “but can you just throw AI at this?”
You go to your LLM prompt library, select a robust prompt, and input it into Claude, along with the spreadsheet.
Four seconds later, you get over 1,700 lines of Python code. Somewhere inside, there appear to be all the data transformations, calculations, and visualizations you need to build your report.
But there’s a hiccup.
Your stakeholder remembers that your tax jurisdictions change four times a year and wants to ensure that you can make any necessary changes.
Sure, you think, that shouldn’t be a problem. I can probably find that line of code somewhere …
Also, there are three subsidiaries. Someone else handles those taxes, so you’ll need to filter those out.
Finally, your stakeholder remembers that your CFO will want to sign off on this and that your auditor is coming tomorrow. They’ll both want to see the logic behind your report.
Suddenly, parsing through and validating hundreds of lines of AI-generated code seems far more difficult and time-consuming than you’d hoped.
VURA: The missing piece
While AI can bring incredible levels of automation and speed, those are only force multipliers when directed strategically.
“I can get an infinite number of PowerPoints out of the AI systems if I want that,” Ethan Mollick recently told me during our executive exchange. “It may even be good content, but if it doesn’t serve the purpose you need it to, the productivity gains become a trap.”
Ethan’s point is that more isn’t always better; bringing four hundred PowerPoints to a sales call won’t help you close a deal. Likewise, instantly generating hundreds of lines of Python is unlikely to help your CFO feel confident in your AI’s vibe-coded report.
For an AI workflow to be trusted, it has to be Visible, Understandable, Repeatable, and Auditable, or VURA. You need to know what’s happening at every step of the process: where the inputs came from, how business logic was applied, and whether the outputs were correct.
So, how can you accomplish this?
The transformation and business logic layer
Let’s try a different AI-powered workflow. Same situation and model. Only this time, we’re going to add a visual transformation and business logic layer.
First, we go into Claude and type up a prompt, but instead of Python, we ask for an Alteryx workflow.
We open our workflow in Alteryx, and instead of hundreds of lines of AI-generated code, we see a visual canvas showing the entire tax reconciliation process.
It’s still an AI-generated workflow, but now, anyone in the organization can inspect it. They can see what data was used. Your analysts and domain experts can validate the logic. And you can add governance and repeat the process.
Suddenly, AI-generated workflows become far more trustworthy and scalable, giving you a foundation for enterprise intelligence.
The future of enterprise AI workflows
AI tools that can’t adapt when the business changes have short shelf lives, and rebuilding from scratch constantly drains tokens, time, and energy. Endless iterations create endless chances for inconsistencies and errors.
With a visual business logic layer, the people who know your business best — your business analysts, sales professionals, finance team, and more — can apply their expertise to your AI workflows and validate its outputs. They can see what’s happening at every step of your AI workflows so that every process is Visible, Understandable, Repeatable, and Auditable.
Speed and reliability are no longer mutually exclusive. Now, you can bring AI’s power and your business experts together to create something fast and reliable, the intelligent solution you need to create scalable business value.
There’s a version of this story you’ve probably lived. The close is approaching, someone pulls a number from a file that hasn’t been updated, and an hour later you’re untangling a discrepancy that shouldn’t exist. The fix takes 20 minutes. Finding the source took two days.
This is the part where most articles would tell you to ‘ditch the spreadsheet.’ But that’s not the real problem, and honestly, it’s a little insulting to the work you’ve actually done.
Your spreadsheet isn’t the issue. The process built around it is.
The logic is real. The medium is the limitation.
Think about what lives in the workbooks your team maintains. How revenue maps to each entity. What counts as a valid reconciling item. The variance threshold that triggers a review. The intercompany elimination logic that took a year to get right. None of that is just data — it’s institutional knowledge. It’s business logic, and it belongs to finance.
The problem is that spreadsheets were never designed to share that logic, version it, or let anything else use it reliably. When a process lives in a file on someone’s desktop, it’s invisible to every system downstream. You can’t hand it off cleanly. You can’t audit it without opening every tab. And when the person who built it leaves, a piece of your operations leaves with them.
Why this matters more now than it did two years ago
A lot of finance teams are under pressure to adopt AI — for close acceleration, anomaly detection, forecast assistance, narrative reporting. The pitch is compelling. The results, so far, have been uneven.
Here’s why, and this part is specific to finance: AI can process data at scale and surface patterns quickly, but it cannot enforce your cost allocation methodology, validate your intercompany eliminations, or know what your organization has decided counts as an exception.
For a tax team, that means it can’t apply your jurisdiction mappings reliably. For an audit team, it can’t reproduce your evidence logic. For FP&A, it can’t honor the constraint assumptions built into your planning model. That requires logic that’s documented, governed, and repeatable — and if that logic is locked in spreadsheets AI can’t see, AI can’t apply it. So it guesses. In finance, a confident guess on a tax provision or a consolidation rule isn’t a minor error. It’s a liability.
The teams getting real value from AI are the ones who built the foundation first and then let AI work on top of it.
The question most teams haven’t answered yet
The shift that helps isn’t about which tool you use but where your process logic lives and who can access it. When your reconciliation rules, transformation logic, and validation criteria exist in governed workflows rather than locked files, the close gets more consistent, errors surface earlier, and handoffs get simpler.
But getting from here to there raises a real question most teams are still working through: what does that transition look like for a tax team, an audit function, or an FP&A group that has years of logic built up in Excel? What moves first, what stays, and what does a week of progress realistically look like?
That’s where the specifics matter — and that’s what we’ll get into next.
Most finance leaders at large organizations have made the right investments. A modern ERP, cloud data platforms, planning tools, and more. And now, increasingly, AI — for forecasting support, anomaly detection, close acceleration, and reporting at scale.
The technology stack looks right. But when the board starts asking about results, the returns are harder to point to than the investments were.
What your ERP was built to do — and what it wasn’t
Your ERP is excellent at what it was designed for: capturing transactions, enforcing accounting standards, managing the chart of accounts. It is the system of record, and it performs that job well.
But it doesn’t encode how your organization has decided to handle intercompany eliminations across a complex entity structure. It doesn’t carry your FP&A team’s cost allocation methodology, refined over three budget cycles. It doesn’t know what variance threshold triggers a controller review versus a VP escalation, or how your tax team has mapped jurisdictions for Pillar Two. That logic — specific, documented, organization-defined — isn’t in your ERP. It’s not in your data warehouse either.
For most finance organizations, it lives in spreadsheets. Sometimes in the heads of the people who built them.
Where AI runs into trouble in finance
There’s a finding that gets cited a lot in finance AI conversations: research from MIT found that 95% of organizations are seeing no measurable return on their gen AI investments. Bain & Company looked at the same picture and reached a different conclusion for finance specifically. The fastest payback from AI in finance comes from embedding it in workflows — not from running pilots. The distinction matters because it explains why so many finance AI efforts stall after the proof of concept.
AI can process data at speed and surface patterns across large datasets. What it cannot do is infer your business logic from raw inputs. Without that context, AI outputs in finance look confident but aren’t defensible — and in a function where auditability is a baseline requirement, that gap is not a minor limitation. It validates that trustworthy AI is critical for scaling workflows and AI pilots.
Our own survey of 1,400 IT and business leaders asked what their biggest barriers to success with AI workflows were. One in two (49%) said inaccurate or biased outputs. Further, 38% said it was a reluctance to allow AI to make decisions without human oversight. While you don’t need perfect data to start using LLMs, you absolutely need trustworthy data.
The layer that’s actually missing
The gap between your ERP and your AI ambitions isn’t a data gap. It’s a business logic gap — the layer where your organization’s specific rules, methodologies, and decision criteria live, and where AI needs to operate to produce outputs you can stand behind.
When that layer is built correctly — logic documented, workflows repeatable, outputs traceable — AI has validated, structured inputs rather than raw data it has to interpret. Outputs can be explained to auditors and to the board. And the sequencing question resolves itself: getting the process right is how you adopt AI.
What it takes to build that layer
Closing the gap takes more than a mandate to “use AI responsibly.” It takes three specific things, built and owned inside finance rather than handed off to IT.
A purpose-built data asset for each process. Not another warehouse but a narrow, well-defined data set scoped to one process that reflects how your team measures it, not just what your ERP happens to store.
Encoded logic, not tribal knowledge. The allocation methodology or the variance threshold that triggers escalation — built into a repeatable workflow instead of a senior analyst’s spreadsheet. The shift is building it once; in a form AI can use.
A way to update it when the business changes. Comp plans get revised, tax jurisdictions shift, and the chart of accounts gets restructured after an acquisition. Logic that can only be changed by submitting a ticket to IT will be stale before it’s deployed — the people who own the process need to be the ones who can adjust the rule.
None of this requires waiting for a perfect architecture. The highest-value starting point is whatever process has your analysts fielding the same question, the same way, every single cycle. Encode that one workflow first, connect it to the AI tools your team is already using, and the logic compounds from there: the same governed calculation that answers one controller’s question can feed the scenario model that runs your next planning cycle.
Every CFO I talk to right now is under some version of the same pressure: the board wants AI, the business wants faster answers, and the finance team is often still reconciling spreadsheets. The promise of AI in finance is real. But so is the gap between that promise and what most organizations are able to deliver.
I believe finance leaders need to be asking not simply, “How do we use AI?” but “What would make our data trustworthy enough for AI?”
That distinction matters. AI-ready finance data is intentionally shaped for a specific business outcome, so we can trust what AI produces from it. In finance terms, it’s the difference between having transactions and being able to defend the numbers.
Finance data is uniquely messy, and important
Finance data is messy for rational reasons. We pull from multiple systems — ERP, CRM, payroll, procurement, planning tools, banks, data warehouses, and yes, still spreadsheets.
We live through reorgs, acquisitions, new products, and chart of accounts changes. And when the business cannot wait, we create manual workarounds to keep moving.
That complexity is the context in which we’re now being asked to use AI. It’s no wonder that so many initiatives stall.
The non-negotiables of AI-ready finance data
When Alteryx talks about AI-ready data, I translate it into a few non-negotiables. For finance leaders, this is where the concept becomes practical.
Purpose-built, not “all the data” – AI-ready data should be scoped to the decision or workflow at hand. If I am building a cash forecast, I do not need every field from every ledger table.
Clean and standardized – AI does not politely ignore bad inputs; it often amplifies them. That means your data needs to be deduplicated, standardized across dates, currencies, and units, and mapped to consistent hierarchies.
Combined across sources, with business context – Finance work is inherently cross-source. AI-ready data is joined and enriched so the dataset reflects business reality, not just system silos.
Traceable and transparent – This is where finance leaders should push harder than anyone else. AI-ready data has lineage. It is auditable and explainable, not just at the output layer, but in the data shaping behind it.
Governed and controlled – AI readiness is about data risk management as much as data quality. AI-ready data should live inside a governed process, not a series of hero spreadsheets and copy-paste steps.
Maintainable as the business changes – This is one of the hidden killers of AI initiatives. A one-time cleaned dataset is not AI-ready if it breaks the minute a new subsidiary is added, a cost center structure changes, or a revenue stream appears. AI-ready data has to be built through workflows that can be updated and re-run reliably, not through one-off cleanups.
Where AI-ready data creates value in finance
This is where the concept becomes real. AI-ready data is the difference between value and noise in some of finance’s most important workflows, including:
Close acceleration: When trial balance data, mappings, intercompany logic, and exception rules are standardized, finance can generate more dependable variance flags and automate more of the financial close and reconciliation process.
Cash forecasting: Better-connected bank data, AR/AP, billing schedules, and seasonality drivers make forecasts less likely to be derailed by missing or misclassified transactions.
Anomaly and fraud detection: Clean, aligned vendor master data, payment runs, approval chains, and PO matching help teams reduce false positives and investigate issues faster.
Revenue quality and leakage: When contracts, invoices, usage, CRM data, and credit logic are brought together in a way that reflects the actual economics of the business, AI can help surface patterns that matter.
Narrative reporting: Grounding LLMs in curated, reconciled variance drivers and approved definitions allows teams to draft commentary responsibly within clear guardrails.
Filling the AI data readiness gap
I’ve found that in most organizations, there’s a constant friction point between data engineering and finance. Engineering understands the architecture, pipelines, and platforms. Finance understands the business context and logic — how revenue is recognized, how allocations work, where the exceptions hide.
The handoff between those groups is often slow and messy. Analysts build fragile workarounds. Engineering teams inherit backlogs of finance requests that are actually business critical.
What resonates with me about Alteryx is that it sits in that gap. It enables finance and business analysts to build repeatable data workflows for extracting, cleaning, joining, enriching, and shaping data for specific finance use cases.
It emphasizes transparency and traceability, and it supports a model where IT can govern, and finance can execute. Just as importantly, it helps organizations turn their existing ERP, warehouse, and cloud investments into outputs that are actually usable for analytics, automation, and AI.
How to get started
If you want to make progress without boiling the ocean, my practical advice is simple: start small and start right.
Pick one workflow that is high pain and highly repeatable (recs, allocations, forecasting inputs, reporting packs).
Define what “trusted” means: the reconciliation rules, thresholds, approvals, and audit trail you need.
Build the AI-ready dataset first cleaned, joined, governed, and repeatable.
Then add AI where it makes sense (classification, summarization, exception explanation) inside the workflow, not as a free-floating tool.
My bottom line is this: AI-ready data is an operating standard. It is how we scale AI without scaling risk. And for CFOs, that should be the real objective, not chasing the latest tool, but building the trusted data foundation that makes smarter automation, better decisions, and more resilient finance performance possible.
Say your reconciliation tool flags a break between two ledgers, and now there’s a number that needs an explanation. The AI-generated summary says the mismatch is a timing difference, transaction posted late on one side. Reasonable. You move on.
Then your controller asks which transaction, on which date, and why it posted late instead of on time. And now you’re not looking at an explanation anymore. You’re looking at a sentence that sounded like one.
The four part test behind every AI answer
That gap is the same thing the last piece here named: can you explain where the answer came from, and would the explanation survive someone pulling on it? Most practitioners have been running that check for years, on spreadsheets, on junior staff’s work, on their own numbers before a review meeting. AI just hands you answers that sound complete far more often now, and faster than the checking can keep pace with.
The test itself breaks into a few plain questions, and it’s worth naming them because most people run all four without thinking about them separately:
Visible: Can you see where the number came from?
Understandable: Do you actually understand the logic that produced it, or just the sentence describing it?
Repeatable: Would the same input produce the same answer next time, or is this a one-off?
Auditable: Could someone other than you retrace it if they had to?
Four different failure modes, and an AI-generated explanation can fail any one of them while still reading like a good answer.
Why the gap is widening faster than the checking
The reconciliation example holds up because it’s ordinary. Nobody’s arguing AI shouldn’t touch reconciliation work. Matching balances, drafting a first-pass explanation for a variance, flagging what needs a human look — that’s real time back. The problem isn’t the AI doing that work. It’s that the logic behind “this is a timing difference” has to already be defined somewhere the AI can point to. If it isn’t, the model is pattern-matching its way to something plausible, and plausible is not the same as traceable.
Deloitte’s Finance Trends 2026 survey of over 1,300 finance leaders found 63% have fully deployed AI in their departments, with only 21% reporting clear, measurable ROI. That’s a broader adoption figure than an explanation-quality study, but the gap it points to lines up with the reconciliation example: plenty of AI running, not much of it yet standing up to scrutiny.
Where the logic has to live
Closing that gap starts with what the AI is drawing from in the first place, before it ever produces an answer. Every explanation an AI generates borrows its logic from somewhere: a threshold for what counts as material, a rule for what makes something a timing difference, an assumption about which system wins when two ledgers disagree. When that logic lives only as a pattern the model has inferred from past examples, the explanation is a guess dressed in confident language. When it’s defined, owned, and applied the same way every time, the AI has something real to summarize.
Finance has kept this kind of logic for as long as the job has existed, often in a spreadsheet somebody built years ago that everybody trusts without fully remembering why it works. That logic hasn’t changed. Who can now touch it, and how fast, has, and that means the definitions underneath it need to hold up to more traffic than they ever have before.
If you want to see what that looks like in a live workflow rather than in the abstract, Alteryx’s AI-Ready Starter Kits are pre-built Alteryx workflows and synthetic datasets designed to demonstrate how Alteryx can be applied to specific business use cases. They prepare and structure data to produce analysis-ready outputs, which can be extended using external AI tools.
The Reconciliation Exception Resolution AI-Ready Starter Kit shows the pattern from this piece in practice: exceptions routed to an owner, prioritized by materiality, and documented consistently enough that the resolution holds up when someone asks how you got there.
There’s a specific moment every finance leader knows. A number is about to leave the building — headed for the board deck, the earnings call, or the audit committee — and right before it goes, you pause. You want to know where it came from, and you want to know it will still make sense if someone asks how you got it. That pause happens no matter what produced the number.
That instinct shows up in the data too. In a Gartner survey of more than 200 CFOs, confidence across finance leaders’ top 2026 priorities averaged around 63%, while confidence in driving enterprise AI impact came in at just 36%.
Leaders aren’t lacking confidence broadly. They’re confident about cost discipline and growth investment. The drop is specific to AI. It’s a broader measure than any single number leaving the building, but it points in the same direction: AI is the one place finance leaders can’t yet count on the confidence that usually comes easily.
The four things every number has to pass
That pause is a fast version of a test. Before you’d trust a number, you check four things:
Where it came from
Whether you could explain it simply
Whether it would come out the same way twice
Whether you could trace it back through the data if someone asked
Most finance leaders have never written that test down. They’ve never had much reason to, because until now, the systems producing their numbers usually held up well enough that the check rarely turned into a real problem.
AI doesn’t automatically pass that test. It can produce a plausible answer to almost anything, including things it has no real basis for knowing, and the answer looks the same whether the logic underneath is solid or made up. That’s the real source of the confidence gap.
Leaders don’t doubt that AI can help. They doubt whether they could explain the answer if someone pushed back on it. The four things finance leaders already check for come down to four words: visible, understandable, repeatable, and auditable, or VURA. Those words succinctly describe what leaders were already checking for instinctually.
Who owns the logic underneath
Naming the test doesn’t resolve where it gets applied, though. That takes a harder answer about where the logic itself lives. Deterministic logic is defined by finance, not inferred by AI. A model can draft a variance commentary, summarize a forecast, or flag an anomaly worth a second look.
It should never be the one deciding what counts as an exception, how revenue gets recognized, or which threshold triggers an escalation. Those are calls finance makes, and AI’s job is to work within them, explain them, and apply them consistently, not to invent them when it doesn’t have enough to go on.
That distinction is where most AI disappointment in finance actually starts. The model usually isn’t failing at what it’s good at. The failure happens earlier: nobody defined the logic it needed, so it guessed, and it delivered that guess with exactly the same confidence it would use for a right answer. Looking at the output alone, you can’t tell the difference.
That’s exactly what the four-question test catches. Ask where the number came from, whether you can explain it, whether it repeats, and whether you can trace it back to the data, and you’ll find out fast whether the AI applied logic finance defined or made something up that looks close enough.
Building the standard into the workflow
This is an architecture decision as much as a governance one. The four questions get easy answers when there’s a layer between raw enterprise data and the AI consuming it, one that prepares the data, holds the logic finance owns, and keeps every output traceable back to both.
That’s the role Alteryx plays. It doesn’t compete with the model doing the reasoning, and it doesn’t replace the ERP or EPM system the data lives in. It’s the business logic layer that makes sure what reaches the model is something finance already stands behind, so the model’s output can be too.
Build that in, and the pause before the number goes out changes what it’s doing. Instead of hoping the number will hold up, you can check that it does, every time, because the answers to those four questions are already built into how the workflow works, not something you have to reconstruct from memory.
If you’re looking for a concrete way to see what that looks like on a real workflow, take a look at our AI-Ready Starter Kits: pre-built Alteryx workflows and synthetic datasets designed to demonstrate how Alteryx can be applied to specific business use cases. They prepare and structure data to produce analysis-ready outputs, which you can then extend using external AI tools such as large language models.
Understanding why finance leaders hesitate to trust AI is only the first step. The next is building the governed foundation that gives AI reliable business logic to work from.
Learn more in Building Finance AI You Can Trust, where you’ll explore the principles and practical steps behind AI-ready finance workflows.
Entrar
