The ICT sector consists to a large extent of work that can be broken down into recognizable steps: writing code according to a specification, testing against fixed criteria, maintaining documentation, triaging tickets, configuring infrastructure, compiling reports. Alongside that is work that cannot be captured in steps: an architecture choice that will last for years, a client describing a problem no one has solved yet, a team having to weigh a deadline against a quality requirement. Both kinds of work sit within the same roles, often with the same person on the same day.
That mix explains why AI does not arrive here as a project but as a gradual shift. Part of the work was always labour-intensive without being complex: converting code from one language to another, generating test scripts, searching logs for a known pattern. As soon as AI takes over that part fully or partially, nothing changes in the strategy on paper — the roadmap, the client promise, the service level all remain in place — but the assumption underneath it, namely how many people and hours are needed to deliver that promise, is no longer automatically true.
What is happening in ICT cannot be summarized as "AI replaces programmers". The work splits into three categories that run through almost every role. Some tasks AI can carry out independently: generating structured code, translation steps between systems, repeatable tests. Other tasks proceed partially: AI produces a proposal — a code change, a risk assessment, a summary of an incident — and a person approves or rejects it, with a reason that is recorded. And a third category remains human work: the conversation with a client about what they actually mean, the decision to put a system into production or not, the responsibility for what goes wrong.
The division between these three is not fixed. In a company with many legacy systems and little standardized documentation, the share of the third category is higher than in a company with modern, well-documented infrastructure. In a team that organizes oversight as a fixed part of the process — someone who actually assesses AI proposals, not just clicks them through — more work shifts to the second category without loss of quality. In a team without that oversight, AI remains limited to isolated experiments, and little changes, even though the technology is available.
The reason this reaches the boardroom and not just the IT department is that strategies in this sector often rest on an assumption about capacity: how much development capacity is needed to meet the roadmap, how much support capacity to maintain the service level, how much senior time to train juniors. If AI takes over part of the work in the first or second category, the amount of freed-up hours and FTE capacity changes — not by a fixed percentage, that depends on the systems, the discipline in the process and the degree of oversight, but the direction of the shift is certain.
The strategic question, then, is not whether AI is taking over work, but whether the plan still assumes the old division. A roadmap that counts on a fixed development capacity, a pricing model that assumes a fixed number of support hours per client, a training programme built on the assumption that junior work stays the same — these are all assumptions that this shift can quietly invalidate. No one formally withdraws them; they simply remain in the plan while the reality underneath changes. That is a different pattern than, for instance, in financial services, where regulation partly determines the pace of automation, or in construction, where physical execution sets a different limit on what AI can take over. In ICT the boundary is often less physical and less legal, and therefore shifts faster — which makes the risk of a silently outdated assumption more likely to grow than shrink.
Two companies in the same subsector can be positioned very differently here, and that difference rarely lies in the availability of AI tools — those are accessible to both. It lies in whether there is a working oversight mechanism that assesses AI outcomes with a recorded reason, whether the documentation and systems are in order so that AI can do something with them, and whether management has recently had the assumptions underlying the strategy tested against what has already changed operationally. Companies without the latter are steering by a strategy that still looks correct on paper, while the capacity assumption behind it has long since been overtaken.
This shift also raises the question of who should be at the table for such a review — not just management, but also the people who actually see the work changing, as described in an overview of who should take part in a strategy review. Insofar as this shift touches on decisions about personnel, separate statutory requirements apply to those; this page is about strategy, not about those decisions.
The underlying question — which work in this company can genuinely be taken over by AI, which work partially, and which work remains human work — is answered per task by the work scan from FTE TO AI, rather than on the basis of an estimate for the entire sector. Before that scan comes into view, there is a smaller step: the free assumption check, a short round in which you name your main strategic assumptions and see, for each one, when it was last actually confirmed. That reveals which assumptions still hold firm and which have quietly begun to shift. The full strategic stress test, comparing the outside view with management's own self-assessment, is under construction.
Stel uw vraag. Vaak zit de echte vraag een laag dieper — daar mag ik naar vragen.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.