Designing the organization around AI: how roles change

In many mid-sized companies AI arrives the same way. A tool is rolled out, a short training session is held, and job descriptions stay exactly as they were. Results disappoint, and people blame the technology or resistance to change. We think the cause is simpler. The way work is produced has changed, while the way it is organized, controlled and shared out has not.

This article offers a reading grid for leaders of SMEs and mid-caps: what really changes in roles, what does not, and which organizational decisions deserve attention before any effect is expected. It builds on our thinking about why AI tools end up in the drawer and belongs to our Organization & adoption practice.

Start from tasks, not from jobs

A job is a bundle of very different tasks: drafting, checking, looking things up, deciding, managing relationships. AI acts on some of these tasks, rarely on all of them. The practical consequence is that asking "which jobs will AI replace?" is not very useful. The productive question is: "in this process, which tasks change in nature, and who answers for them?"

A rough map is enough, at the scale of a team of ten to twenty people. For each important process, separate production tasks (first drafts, summaries, data entry, research), control tasks (review, validation, exceptions) and judgment tasks (decisions, negotiation, relationships). AI absorbs a growing share of the first category, shifts the second, and leaves the third largely intact.

Four shifts in roles

From producing to reviewing and deciding

The employee spends less time creating a first draft and more time evaluating it. This sounds easier, but it is not: reviewing a text that is plausible yet wrong takes solid domain expertise and sustained attention. The role becomes more demanding in judgment, and that needs to be reflected in objectives, allocated time and, where appropriate, pay.

The process owner

An AI tool embedded in a process needs someone responsible for it: a person who decides what it is entrusted with, measures the quality of outputs, collects feedback and adjusts. In an SME this is not a new full-time position. It is an explicit responsibility, often a few hours a week, given to someone who knows the business rather than automatically to IT.

The knowledge keeper

An assistant is only as useful as the documents it relies on are current, consistent and accessible. Most companies discover at this point that their procedures, price lists and terms exist in several versions. Someone has to own the knowledge base: what goes in, what comes out, who validates. Our use case on speeding up the onboarding of seasonal staff illustrates this well: the value comes as much from putting the content in order as from the tool that serves it.

The middle manager

This is the most stretched role. Managers must split work between people and tools, spot misuse as well as non-use, and maintain quality when the volume handled per person changes. If teams are trained but managers are not, adoption stops at their door. On how to size that effort, see training teams in AI without drowning them.

A worked example, with its assumptions

Take a customer service team of 12 people handling about 1,500 requests a month, at 10 minutes each. Assume, for illustration, that an assistant proposes a usable draft reply for 60% of requests, and that handling time for those falls from 10 to 6 minutes, review included.

The gain is 900 requests times 4 minutes, or 60 hours a month. That is roughly a third of a full-time position, spread across 12 people: five hours each. Two lessons follow.

First, this gain is not a position that can be "eliminated". It arrives in fragments and dissipates unless someone is tasked with redeploying it: to complex requests, to retention, to the quality of answers. Second, upkeep has to be deducted. If maintaining the knowledge base and monitoring quality takes, say, a fifth of a position, about thirty hours a month, half of the gross gain is already consumed. The net benefit therefore depends less on the tool than on how roles are designed around it. For valuing this kind of gain financially, our Finance & performance approach offers a useful framework. The deployment details are in our use case on getting an AI assistant adopted in customer service.

The junior pipeline risk

One question is often overlooked: if AI takes over entry-level tasks, how do we train tomorrow's experts? In Switzerland, where apprenticeships and dual-track education underpin the SME landscape, this matters. A junior who no longer writes first drafts does not learn to recognize a bad one. We recommend deliberately preserving learning tasks, backing them with mentoring, and having juniors review the tool's outputs together with a senior colleague. The cost is modest. What is at stake is the company's competence five years from now.

Accountability and the regulatory frame

Delegating a task to a tool does not delegate responsibility. Three practical markers.

• Every AI use should have a named owner who answers for the result to management and, where relevant, to the customer.
• The revised Swiss Federal Act on Data Protection (FADP), in force since 1 September 2023, requires knowing which personal data is processed and for what purpose, and informing the people concerned. Someone must keep that record current.
• The EU AI Act, in force since 1 August 2024, applies in phases: prohibitions in February 2025, obligations for general-purpose AI models in August 2025, and most other obligations in August 2026. A Swiss company selling into or operating in the EU may be concerned. Classifying uses and documenting human oversight is an organizational task before it is a legal one.

In regulated professions these requirements weigh even more, as we discuss in Healthcare and medtech: getting AI adopted in regulated professions.

What leaders can decide now

1. Map the tasks of two or three key processes, separating production, control and judgment.
2. Name an owner for each AI use, with allocated time and simple quality indicators.
3. Appoint a knowledge keeper, even part-time, before extending the tool.
4. Decide in advance how the time saved will be used, rather than letting it dissolve.
5. Equip middle managers first, then their teams.
6. Protect the junior pipeline with learning tasks and mentoring.

None of these decisions requires a large transformation program. They require clarity about who does what, who controls, and who answers. If you would like to see where your organization stands on these points, our diagnostic is a simple starting point, with no commitment to a deployment.