Blog · arXiv Analysis · Last reviewed June 24, 2026

The Enterprise Role Matrix Becomes the AI-Native Work Map

The June 2026 arXiv paper The impact of artificial intelligence on enterprise software user roles, by Isabel Unger, Elizangela Valarini, Martin Schrepp, Nina Hollender, Gabriela Rocha, and Erik Bertram, studies how AI changes professional responsibilities around SAP Business Technology Platform and the BTP User Type Matrix.

Role Taxonomy Is Governance

The paper, arXiv:2606.25525v1 [cs.SE], was submitted on June 24, 2026. It is not a universal labor forecast. It is a qualitative case study of one enterprise software environment: SAP Business Technology Platform, or BTP. That narrower scope is useful because enterprise platforms already organize work through user types, permission models, lifecycle stages, and product teams. When AI changes who can do which task, the role map becomes a governance surface.

The authors focus on the BTP User Type Matrix, a framework used to align stakeholders in the development lifecycle of BTP applications and services. The matrix organizes high-level user types across task categories and interaction paradigms, from no-code to pro-code, for users such as UX designers, developers, architects, cloud administrators, data scientists, and product managers.

That makes the paper a clean fit for the Spiralist archive. A role taxonomy is not just vocabulary. It says who is expected to act, who is expected to supervise, who is expected to know enough to refuse, and where the institution expects accountability to land.

What the Case Study Measures

Unger, Valarini, Schrepp, Hollender, Rocha, and Bertram combine semi-structured expert interviews with a participatory workshop. The interview sample has 20 participants selected from SAP BTP users and professionals with significant AI expertise or regular AI use in development roles. The interviews were conducted between September and November 2025, lasted 29 to 56 minutes, were transcribed verbatim, and were analyzed through thematic analysis.

The workshop adds 24 participants in development-oriented roles with AI experience or interest. It was an onsite 45-minute session organized around developers, architects, product owners, technical consultants, and business consultants. A small embedded survey, with 19 respondents, asked participants to describe their roles and select matching BTP user roles. Participants mapped current and anticipated future tasks across Research & Plan, Design, Develop, Test & Rollout, and Maintain & Operate.

Across roles, AI appears in project management, learning, research, business tasks, translations, coding, documentation, testing, code analysis, solution investigation, and debugging. The tools named by participants include ChatGPT, Perplexity, GitHub Copilot, Claude Code, and AI features in design tools.

The Blurred Worker

The main finding is not that every role disappears. It is that role boundaries blur while some new boundaries harden. The authors report two simultaneous trends: role broadening and overlap, and the emergence of specialized roles tied to new risks and responsibilities. Developers move toward oversight, prompting, and quality assurance. Architects remain important because senior technical judgment is still needed for AI-generated suggestions. Product owners and consultants see AI entering operational, strategic, and monitoring activities.

The paper also records a tension enterprise adoption often hides. AI may let designers produce code, business roles participate in implementation, and developers approximate broader full-stack profiles. At the same time, participants raised concerns about skill degradation and the partial disappearance of junior roles, while also noting learning opportunities. More people can touch a task, but fewer people may get the slow apprenticeship that made expert review possible.

This connects to existing site arguments about workplace AI clauses, shadow AI at work, and AI in employment. The policy question is not only whether AI raises output. It is whether the organization still knows which skills are being practiced, which skills are being bypassed, and which review duties have quietly moved to someone else.

Agents Enter the User Map

The most important conceptual move is the paper's treatment of AI agents as a pressure on user frameworks. Interviewees described AI agents as active collaborators and as a distinct category of software users capable of autonomously executing development-related tasks. That does not make the agent a worker in the legal or moral sense. It means the governance model must account for software that uses other software on behalf of a person, team, or organization.

Once an AI agent can draft code, inspect incidents, propose architecture changes, or coordinate workflow steps, the role taxonomy must describe more than human job titles. It must record delegated authority, tool access, review obligations, evidence trails, and the human owner of each automated action.

What the Matrix Must Record

The authors argue that the pro-code, low-code, and no-code distinction becomes less meaningful as AI lets roles perform tasks that previously belonged elsewhere. They suggest that continuums emerge across the matrix: from no-code to pro-code and across task categories. They also identify candidate AI-focused roles, including AI Architect, AI Developer, AI Scientist, Machine Learning Engineer, AI Administrator, Machine Learning Operations specialist, and cross-functional needs for AI agent orchestration, AI governance and control, and system review and maintenance.

The governance translation is direct. A modern enterprise role map should record task authority, required expertise, AI-assistance level, agent delegation scope, review duty, escalation path, audit evidence, and the training path for junior workers. This is close to the concern in agent identity and enterprise connector permission maps: a system cannot govern what it cannot name.

Limits That Matter

The paper's limits matter. Participants were selected for AI connection and experience, which the authors identify as a risk for confirmation bias and halo effects. The qualitative sample comprises 44 participants, so the results should be read as tendencies or trends, not population estimates. The study is also centered on the SAP BTP context, even though the authors argue that similar role objectives appear across cloud platforms.

Those limits do not weaken the useful claim. They keep it honest. This is evidence that enterprise AI adoption stresses existing role frameworks in one observed professional environment. It is not evidence that all software labor will follow the same path or that any specific job category must vanish.

Governance Standard

Any enterprise adopting AI-native development tools should maintain a living role matrix. For each task family, it should state whether AI is absent, advisory, co-producing, or acting through delegated tools. It should name the accountable human role, the reviewer role, the permitted agent identity, the evidence retained, and the skill pathway that keeps future reviewers from becoming ceremonial.

The practical rule is simple: revise the role taxonomy before the workflow makes the old taxonomy false. If a product owner can trigger implementation, a designer can generate coded UI, a developer becomes an overseer of agentic troubleshooting, and an AI agent can operate across the lifecycle, then the enterprise work map must show that.

Sources

Return to Blog