putilov_denis - stock.adobe.com

AI turns application administration into business policy

AI does not reinvent application administration. It makes some settings consequential enough that enterprises need clearer decision rights and governance.

AI is not fundamentally changing the basics of enterprise software administration.

ERP, HR, CX, communications and collaboration, and end-user computing applications still need people to manage settings, permissions, access, integrations, workflows, users, updates and controls.

What AI is changing is the consequence of some of those decisions.

An administrative setting becomes a business policy decision when the result has a greater effect on the organization than the setting itself might suggest.

Giving an AI agent read access rather than write access seems like a permissions choice. So does requiring human approval before an agent updates a record or executes a transaction.

But those settings can determine what the AI knows, what it can do and how far its actions can travel.

The person who has the technical ability to change a setting does not necessarily have the business authority to decide everything that setting should allow.

This problem did not start with AI. Enterprise software configuration already reflects how a company operates.

An application role is not just a technical setting. It reflects what someone does in the business, what information they can access and which actions they are allowed to take.

Role-based access control, or RBAC, formalizes that relationship by assigning permissions according to a user's role and responsibilities. With AI, those access decisions can become more consequential. An AI capability operating through a user or service identity might be able to reach the data and actions that identity is permitted to use.

A workflow rule represents an operating decision. A required field indicates data that someone has determined the business needs. Permissions determine who can see, change or approve something.

Diagram showing role-based access control linking business roles to systems.
Role-based access control maps permissions to business roles and responsibilities. When AI capabilities operate through user or service identities, those controls can also help determine what data AI can access and which actions it can take.

That is one reason configuration sprawl can become hidden software debt. Settings accumulate, exceptions survive and what looked like routine administration can become part of the operating model.

AI makes that existing reality more consequential.

The settings are still settings. Administrators still need to know the software and understand how to configure it.

But AI can give the application more ability to act without direct human involvement.

An agent might summarize information, recommend an action, initiate a workflow, update a record or execute something across systems. The administrative decision can therefore establish not only how an application behaves, but how much independent action the enterprise is willing to let AI take.

Familiar controls can carry a larger consequence

The difference becomes clearer as AI moves from helping someone do work toward acting itself.

A meeting summary is relatively bounded. Automated record updates, cross-system data movement or transaction approvals are not.

Brian Fending, managing director of Ordovera Advisory, has described an underlying authority problem in which product owners can "flip toggles" without clear authorization boundaries.

A feature can also look narrowly focused while its permissions let it reach much more data or functionality than the feature name suggests.

An AI capability can inherit permissions associated with the identity through which it operates. An agent might therefore have access to data or actions well beyond the narrow task suggested by the feature itself.

Those AI decision boundaries can cover financial transactions, HR actions and customer activity, as well as the maximum level of access or authority an agent receives and the points where human approval is required.

Get them wrong, and the result can go well beyond a bad setting. Get them right, and the same controls can enable an organization to automate defined work while keeping risk within acceptable bounds.

The administrative question might be whether a feature should be enabled or how a permission should be configured. The larger business question is what the enterprise is authorizing AI to do.

5 signs an AI admin setting needs broader review

Not every setting needs cross-functional approval. But a routine administrative change might need broader review when it:

1. Expands data access.
The AI can reach new records, systems or categories of sensitive information.

2. Adds autonomous action.
The capability moves from summarizing or recommending to updating records, initiating workflows or executing transactions.

3. Affects employees or customers.
The setting influences hiring, performance, service, communications or any other interaction with people.

4. Changes human oversight.
A person who previously reviewed an action is removed from the process or becomes responsible only for exceptions.

5. Creates a larger enterprise consequence.
The change introduces meaningful cost, compliance, security, records management or cross-system effects.

The goal is not to elevate every application setting. It is to recognize when the consequences of the setting outweigh the administrative action itself.

Technical ownership does not settle business authority

The same technology can carry different consequences for different parts of the organization.

CVS Health's work with ServiceNow across HR and IT illustrated that problem across HR, IT, procurement, store operations and other groups.

IT could focus on efficiency and call deflection. HR had to care about the accuracy of information delivered to employees and the potential effects on compliance and employee relationships.

The platform is shared. The consequences are not.

That means the team that administers an application cannot always evaluate a setting only from the perspective of keeping that application operating correctly.

Security might need to become involved when access expands. HR and legal might need to be involved when a capability affects employees. Privacy or records teams can become relevant when AI creates or retains new information. Finance can have a role when a feature introduces meaningful consumption-based cost.

There is also not necessarily one universal business owner who can settle every decision. Many enterprise processes are too distributed for that.

Governance needs layers, not one AI owner

No single person or group can or should decide whether every AI feature gets enabled.

The application team understands the application and its configuration. Governance can establish broader rules that apply across the organization.

Security, privacy, legal, HR, finance and other functions make decisions within their areas of responsibility.

Enterprise leadership has another role: to set the organization's broader operating expectations and tolerance for risk so the people making individual decisions have a common framework.

Rimini Street's layered AI governance approach includes an AI steering committee with HR, IT, legal and business representatives, while access can differ according to what employees or agents are allowed to do.

The controls can become as specific as whether an agent receives read or read-write access to data. The company has also rejected proposed AI uses, including one involving individual employee performance assessment.

That is clearly more than an application-setting decision.

HR provides another obvious example. AI used in hiring, performance management and promotions can create legal and organizational implications that require HR, IT and legal to agree on the framework rather than treating deployment as a technical decision alone.

The goal is not to take routine administration away from application teams. It is to make the authority boundary visible.

An application setting can have effects beyond the application

AI also does not exist in a vacuum, separate from the application where it appears. Neither do identity, security, governance, data, nor interoperability.

These issues cross the traditional boundaries separating ERP, HR, CX, communications and EUC.

An agent can appear within one application while relying on data from another, invoking actions elsewhere or handing off work to another system or agent.

AI makes the limits of category-based software management more visible. But it did not invent them.

The setting can belong to one application, while the consequence might apply to the entire enterprise.

Applications still provide necessary expertise and ownership. But a setting might reside within one application even when its effects extend to other systems, workflows or business functions.

A collaboration administrator, for example, might configure AI controls for meeting summaries, transcripts and retention. Those controls can touch security, records, privacy and compliance policies outside the UC team.

The setting can belong to one application, while the consequence might apply to the entire enterprise.

Not every toggle belongs in a committee

The answer is not to govern every setting as if it were an enterprise transformation. That would be impossible.

Modern enterprise environments have too many applications, configuration choices, permissions and routine changes. Application teams must retain the ability to administer their systems.

The more useful question is whether changing the setting could have consequences beyond the application or task it appears to control.

Expanding data access can be one signal. Giving AI additional autonomous authority can be another.

So can changes that affect employees or customers, alter human-review requirements, create enterprise records, introduce meaningful cost or regulatory exposure, or affect work outside the application where the setting lives.

Those are not universal rules. Every enterprise has its own environment and tolerance for risk. But organizations need to recognize that the distinction exists.

Otherwise, the administrative structure can quietly become the policy structure. Whoever has permission to change the software can end up making a business decision simply because no separate decision process exists.

The hidden work is becoming business work

AI is making the behind-the-scenes work of enterprise technology more important. That includes governance, testing, configuration, integration, permissions and clear ownership of workflows.

It also puts more pressure on IT and business teams to understand how technical changes affect the way the organization actually operates.

The basics of application administration remain. What changes is how much can go right or wrong because of an administrative decision.

That puts familiar enterprise AI lessons back in the foreground: Know the environment. Use trusted data and enough business context. Define permissions and decision boundaries. Understand the workflow. Keep people involved where the risk requires it. Coordinate systems and agents.

Application administrators will implement many of those decisions.

They should not have to invent all of them.

AI does not fundamentally change application administration.

It makes clearer which parts of application administration were business policy all along.

James Alan Miller is a veteran technology editor and writer who leads Informa TechTarget's Enterprise Software group. He oversees coverage of ERP & Supply Chain, HR Software, Customer Experience, Communications & Collaboration and End-User Computing topics.

Next Steps

How AI leaders can build an AI feature inventory

Agentic governance must go beyond traditional IT practice

AI operating models: Balancing autonomy and human oversight

Best practices for integrating third-party AI with local systems

Best practices to conduct a user access review

Dig Deeper on Communications & Collaboration