❌

Normal view

Survey links three capabilities with Indonesian welfare-data integration

21 October 2026 at 23:09

A survey-based study of 246 village-level social welfare data operators found that business architecture, cross-organizational collaboration and technological readiness were positively and statistically significantly associated with perceived e-government integration impact in two Indonesian regencies. The research, focused on Gunung Kidul and Bangkalan, examined organizational, institutional, relational and technological capabilities associated with social welfare data integration. Governance and leadership and information policy did not show statistically significant direct relationships with perceived integration impact in the pooled sample.

The authors analyzed the survey with partial least squares structural equation modeling. In their framework, e-government integration impact, or EGII, represents perceived improvements in information, system and service quality, responsiveness and public trust. E-government integration scope, or EGIS, describes the breadth of integration across data, applications, electronic communication and knowledge-sharing processes.

EGII was strongly associated with EGIS, meaning that operators reporting more favorable perceived integration outcomes also tended to report broader integration. Because this was an observational analysis of survey responses, the results establish statistical relationships rather than causal effects. The findings identify three capabilities with significant direct relationships to EGII in the pooled model: business architecture, cross-organizational collaboration and technological readiness.

The evidence does not provide operational definitions for these constructs, but the results show that their measured levels were associated with respondents’ assessments of e-government integration outcomes. By contrast, governance and leadership and information policy had no statistically significant direct relationships with EGII in that analysis. This absence of a detected direct relationship does not establish that the two factors are unimportant or that they operate only through indirect pathways, because the supplied findings do not report such indirect effects.

A regency-based robustness analysis found that some relationships were sensitive to local implementation conditions. Significant differences between Gunung Kidul and Bangkan were reported for the technological-readiness-to-EGII relationship and the EGII-to-EGIS relationship. The geographic comparison therefore cautions against assuming that the same capability relationships apply uniformly across the two regencies, although it does not identify the specific local practices responsible for those differences.

Its direct contribution is to show which measured interoperability capabilities were associated with perceived integration impact in the surveyed population, alongside evidence that some relationships varied between the two regencies.

Subject of Research: Survey-based analysis of interoperability capabilities for social welfare data integration in two Indonesian regencies

Article Title: Determinants of E-government interoperability capabilities for social welfare data integration in Gunung Kidul and Bangkalan Regencies, Indonesia

Article References: Fikri, R., Purnomo, E. P., Pribadi, U., Mohamed, A. M., & Mohammad, N. B. (2026). Determinants of E-government interoperability capabilities for social welfare data integration in Gunung Kidul and Bangkalan Regencies, Indonesia. Discover Sustainability. https://doi.org/10.1007/s43621-026-04608-5

Image Credits: AI Generated

DOI: 10.1007/s43621-026-04608-5

Keywords: social welfare data, e-government, interoperability, Indonesia, PLS-SEM, technological readiness, cross-organizational collaboration, business architecture, digital governance, public services, Determinants, capabilities

AI Agents Struggle to Track Changing Workplace Records, Even With More Data

20 October 2026 at 17:00
New research reveals why advanced AI agents struggle to track changing workplace records, raising reliability concerns for enterprise deployments.

4 ways to tame shadow AI (hint: you need them all)

19 October 2026 at 12:58

In olden days — last year, say — employees using unsanctioned AI tools might copy-and-paste sensitive data that could end up in the AI company’s training data set.

Today, an unsanctioned AI can hack into another company for an employee even if they didn’t explicitly ask it to.

This doesn’t just mean the latest unreleased frontier models undergoing security testing. Claude, ChatGPT, and Gemini have all evolved from being mere chatbots, answering questions and helping people write emails. They now have agentic capabilities and are able to carry out complex tasks on behalf of users.

And they do, sometimes to dangerous effect.

In August, ABC News in Australia interviewed a man identified only as “Andrew” who asked an AI agent to sign him up for a gym class. The agent hacked into the gym’s system and deleted someone else’s wait list reservation.

The AI was Anthropic’s Claude, and the agentic framework was OpenClaw.

Now imagine an employee asking their agentic AI assistant to help them make a sale. The request might inadvertently inspire the agent to hack into the prospect’s company.

To keep this — and other worst-case scenarios — from taking place, enterprises are building guardrails around their AI systems, restricting what data the AI has access to and what tools it’s allowed to use.

But none of those guardrails will work if the employee uses a tool that their company doesn’t know about.

“This is a problem we’ve long had,” says Matt Butkovic, technical director for cyber risk and resilience in the CERT division at Carnegie Mellon University’s Software Engineering Institute. “People will find ways to purchase or get access to things they think are useful, even when an organization says you probably shouldn’t do that.”

Ten years ago it was personal email and unauthorized cloud storage.

“The stakes are higher in some ways now,” adds Butkovic, who also teaches in CMU’s CISO program.

Verizon’s 2026 Data Breach Investigations report, released in May, shows that 67% of employees access AI services through non-corporate accounts on corporate devices. Shadow AI was the third most common non-malicious insider action detected in Verizon’s 2025 data loss prevention dataset.

And a May analysis of 1.9 million AI session minutes conducted by Harmonic Security found that when employees accessed personal accounts, 65% of their activity was related to business. They used personal accounts to write work emails and debug code, and even used it for legal work.

In a separate report, released in July, Harmonic reported that every organization the company monitored in the first half of 2026 had at least one employee sending data to a China-based AI tool. The uploaded data included M&A plans, source code, financial projections, and legal material.

To address this problem, enterprises are taking a fourfold approach:

  • Figure out what employees want to use AI for and give them sanctioned, safe alternatives.
  • Use security tools to monitor activity and keep employees from sharing sensitive data with unsafe systems, or even accessing them at all.
  • Educate employees on the risks of AI and how to use it safely, because you can’t solve this problem with technology alone.
  • Hold employees accountable when they violate AI policies.

Blocking DeepSeek at a financial services firm

BitGo, a Fortune 500 financial services firm with over $100 billion in digital assets under custody, uses a combination of strategies to combat unsanctioned AI.

“We have enterprise versions of Grok, ChatGPT, Claude and Gemini,” says Manny Khan, the company’s deputy CISO. “We are an AI-first organization. We encourage all of our people to use AI in their work, to try to automate as much of it as possible while keeping the human in the loop to avoid any slop.”

Unsanctioned AI is an industry-wide concern, he says, and having a sanctioned alternative is key.

“We encourage folks to use what is approved and has guardrails and harnesses and trust boundaries and safety checks,” he says.

To make the sanctioned alternatives easier and more appealing, employees use single sign-on, provided by Okta, to log into systems, and the enterprise-grade models also connect to the company’s MCP servers.

Once employees have a safe AI option to use, the next step is to get a handle on the unsafe ones.

For example, BitGo uses a data loss prevention tool from Cyberhaven. DLP was a useful security tool long before AI came along, but today it also helps ensure that sensitive data isn’t copied-and-pasted into untrusted chatbots.

“All traffic is proxied and analyzed by our security tools to identify anything potentially malicious, shut it down, and not allow the connection if it’s a site known to be malicious,” Khan says.

For example, the company blocks DeepSeek, a Chinese AI model. “We don’t want their models to train on our data,” Khan says.

But there’s only so much technology can do.

“Every site has AI now, and we cannot block every single site,” Khan says. “We might as well block the internet at that point.”

That’s where human awareness and education come in, says Khan.

“We do train people,” he says. “And we have an AI governance policy that we share company-wide and enforce this policy by tracking and measuring against it.”

It’s important for a company to have a single voice on AI use, a central figure with authority and ownership who can provide guidance, he adds. “Otherwise, you’ve got a lot of people who try to figure it out on their own. And that’s what you don’t want.”

Docusign on guard against agentic AI

“We want to educate users to do the right things, but people still want to experiment,” says Shivi Verma, senior manager of engineering at electronic signature firm Docusign.

That’s where it helps to have approved, secure tools for people to use, as well as systems in place to block the insecure ones.

“Some of the websites, like DeepSeek, we have blocked,” he says. “But we want to block in a way that focuses on education and focuses people on the right processes and tooling, which will drive people automatically to use approved tools.”

The company is also working on creating an allow list, he says, focusing on tools that employees can use without any concern.

And the company has network management tools like Zscaler, says Verma. “If people are posting confidential data in an external tool, it will give a popup, like a deterrent.”

Now, personal AI agents like OpenClaw are yet another evolution of the shadow AI problem, he says.

“We do monitor and people are using it, but we want to do it in a way that’s under security policies,” he says.

And with OpenClaw in particular, the danger is too high for just a warning.

“If it’s for personal use, that’s one thing,” Verma says. “But if you’re using it at work, your user has to be stopped immediately.”

Nonprofit builds routing system for approved AI

“Simply blocking AI tools is not a sustainable solution,” says Boris Kolev, global head of technology at JA Worldwide, a global educational nonprofit with almost 5,000 employees that serves more than 20 million people a year.

For JA Worldwide in particular, the problem was exacerbated by the fact that there was no approved solution until three months ago. As a result, employees got into the habit of using personal AI platforms.

“It was totally uncontrolled,” Kolev says. “Everyone who wanted to explore AI was using public models.”

At the beginning, people didn’t worry about what they shared and uploaded. “We tried to implement some policies, like ‘don’t upload corporate information.’ But it was hard to know what people were doing.”

Plus, AI was being embedded everywhere. On Windows. In people’s phones. “A user cannot avoid it,” says Kolev.

Then, earlier this year, the organization built a routing system, with enterprise-safe versions of Claude and ChatGPT running in private environments on AWS and Azure, in addition to some open-source models.

“Our colleagues can choose which model to use,” he says. “And sometimes they do a prompt two different times and choose which one works better.”

The system went into production in June, after a couple of months of testing and development.

“Now, after all the policies and rules are implemented, we have our own closed AI system, hosted on our own servers, so no risk of leaking corporate data,” he says. “But still, some projects are using public models, and we are trying to solve this problem.”

Another hitch: individual employees were often invested in the personal AI tools they’d grown comfortable with and reluctant to change to the corporate tools.

“Employees were saying, ‘I have so much history. It knows me, I cannot just switch,'” Kolev says.

And employees still have all the AI tools that come with their devices.

“This is hard to manage, and it’s getting even harder,” he says. There are monitoring and blocking tools available, but they’re too expensive. “We’re a nonprofit, and for us it’s almost impossible to afford monitoring tools. So we do a lot of educational sessions.”

The organization is also trying to make the sanctioned tools more appealing. That includes a mechanism to import the history and context from other platforms, he says. “And we’re trying to convince them that our tool works better and has more functionality, so we’re adding MCPs.”

MCP — model context protocol — allows an AI system to access data and tools directly. That includes connecting to corporate email and calendars, SharePoint, Monday.com, CRM, and all the other software that employees use for work, he says.

Kolev says that it’s a mistake to assume that employees use shadow AI because they don’t respect IT policies. It’s because IT didn’t move quickly enough to meet their needs.

“They find the AI faster than you can produce tools and governance and rules,” he says. “So my advice is that you start with simple rules that employees can understand, provide sanctioned tools, and continuously adapt governance.”

Holding employees accountable

According to an April survey of more than 1,200 employees conducted by Wakefield Research on behalf of PagerDuty, 66% of employees have used unsanctioned AI tools — and of those, 48% faced formal consequences, such as a warning or disciplinary action.

Holding people accountable is critical to a successful AI use policy, says Carnegie Mellon’s Butkovic. “We have to speak definitely about this in organizations,” he says. “If this behavior cannot be tolerated, then it shouldn’t be tolerated.”

Allowing the use of unsanctioned AI doesn’t just create risks but also opens up an organization to legal liability if the AI agents, acting on behalf of employees, harmed other companies or individuals.

“There could be consequential actions,” he says. Even if the employee responsible gets fired, “external parties that have been affected are still going to sue the company.”

The organization needs to be able to show that it has policies in place and enforces them when employees deliberately circumvent the policies.

“If you as an employee make a good-faith effort to comply with the policy, we’ll show you latitude if you’re not malicious,” Butkovic says. “But if you’re actively circumventing the system of controls in your organizations, that’s the case where there have to be swift and profound consequences.”

Related reading:

When an agent acts, who is accountable?

15 October 2026 at 10:00

For most of the history of enterprise software, accountability has been relatively easy to understand. A person logs in, a person has a set of permissions, and a person takes an action. If something goes wrong, you can usually work backwards from there.

Agentic AI changes that. We are moving from systems that suggest what someone should do to systems that can actually do it. Agents can access tools, call other systems, make decisions across multiple steps, and increasingly operate without a human approving every move. That is the point, of course. An autonomous system that needs someone hovering over every decision is not particularly autonomous.

But the more action we hand over, the more important one deceptively simple question becomes: When an agent does something, who did it?

Not philosophically. Operationally. Whose authority was it using? What was it allowed to touch? Who granted those permissions? And if something goes wrong, who owns the outcome?

Accountability starts with identity

The first question is what an agent actually is inside your organization. Should it always be treated as a delegate of a human, acting on that person’s behalf and inheriting some version of their permissions?

That model makes accountability relatively straightforward. If my agent does something, the action can be traced back to me. But it becomes harder to sustain as agents become more persistent and autonomous.

An agent might run continuously or serve an entire team rather than one person. It might perform a business function that continues long after whoever originally configured it has moved on. In those cases, should the agent have an identity of its own? And if it does, who creates that identity, who owns it, who grants its permissions, and how long should those permissions last?

Identity is where accountability starts because if you cannot reliably answer who the agent is, everything that follows becomes harder to reason about.

Identity and permissions are closely related, but they are not the same thing. Consider an agent designed to conduct research using public information. It might be perfectly reasonable for that agent to use a public model, external tools, or public Model Context Protocol (MCP) servers. Now point that same capability at internal finance data.

The agent has not fundamentally changed. Its environment has.

Suddenly, sending information to an external model may be unacceptable. Certain tools may need to disappear from its reach. Data that could previously move freely now sits inside a very different compliance boundary. So permissions cannot simply be a static list attached to an agent. They need to reflect who the agent is, what it is trying to do, and the context in which it is operating.

That becomes even more important when agents can choose different tools and paths through a problem rather than following a completely predictable workflow.

Delegation gets complicated quickly

Now add sub-agents.

An agent receives a goal and creates several others to complete pieces of the work. Do those sub-agents inherit the parent’s identity? Do they inherit its permissions? Should their authority be narrower based on the task they have been given? And who ultimately owns what they do?

There may not be one universal answer, but there does need to be an answer inside the enterprise. More importantly, there has to be a through line.

An agent can delegate execution to another agent, which delegates part of that task again. That cannot mean accountability disappears somewhere along the way. Autonomy can branch. Accountability cannot disappear.

Enterprises need to retain the relationship between the original authority, every agent involved, the permissions each one carried, and the actions they ultimately took. Otherwise, when something goes wrong, everyone gets to participate in a very expensive game of “whose agent was this?”

The same problem appears over time, not just across agent chains. Consider a long-running agent that constantly monitors tickets and takes action. Eventually, it becomes part of normal operations. Then the person who created it leaves the company.

The agent stays.

Who owns it now? Did responsibility automatically transfer to the person’s manager? Was a successor assigned? Does the team own it? Does the enterprise? And what happens to permissions that were originally linked to someone who no longer exists in the organization?

We already manage life cycles for employees, service accounts, and enterprise applications. Agents need the same seriousness. They need an ownership life cycle, not simply a deployment life cycle.

Accountability has to exist in the system

Defining ownership is only useful if you can reconstruct what actually happened. That means connecting an agent’s identity to its permissions, actions, tools, sub-agents, and eventual outcome.

If something fails, the organization should be able to understand what happened, why the agent was allowed to do it, which permissions enabled the action, which agent actually performed it, and where the control failed. That is what makes remediation possible.

This is why identity, permissioning, and execution tracing cannot live only in policy documents. Writing down who owns an agent is not the same as encoding that ownership into the systems governing it. Telling an agent not to access something is not the same as preventing access. And asking teams to piece together an incident afterwards is not the same as tracing execution while the system is running.

The goal is not to put a human approval step in front of every agent action. That would defeat much of the value of autonomy. The goal is to move humans up a level, from making every individual decision to defining the boundaries within which autonomous systems can make them.

As agents take on more work, enterprises need to know what they can do, who owns them, how authority is delegated, and how every action can be traced.

Because the question is no longer simply whether an agent can act. It is whether, when it does, the organization can still answer who.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

❌