The ICT sector holds a position no other sector has: here, AI is not just used, it is also built, integrated and resold. A developer connecting a language model to an application, a consultant embedding an AI feature in a client project, a team fine-tuning an open-source model — these are not exceptions, this is the daily work. The balance between what the organization itself decides and what an individual employee or team adds on their own is different in this sector than in a bank or a construction company. Where in other sectors AI is an addition to existing processes, in the ICT sector AI is often part of the product itself. That means governance is not only about internal tools, but also about what is contained in software delivered to third parties.
In many sectors, the IT department is the one with visibility into what is running. In the ICT sector, that assumption is weaker than elsewhere, precisely because almost everyone has the technical knowledge to request an API key, download a model, or embed an AI feature in a codebase without any request, license or approval process preceding it. A developer using a language model to generate code, an architect testing an AI agent in a sandbox, a sales team building a demo with an external model — those choices are made at the project level, not at the board level. An inventory that starts with purchased licenses therefore misses a substantial part of what is actually happening. The question is not whether there is shadow AI, but how much of the production environment now depends on it without anyone having recorded that.
The technical means to detect AI use exist, but they often only see what runs through company networks and managed devices. In a sector where a lot of work takes place in own development environments, personal accounts and client projects with their own infrastructure, that is a limited picture. The most complete information comes from the people doing the work. That only works if the question is asked without consequences: someone who knows that an honest answer leads to a sanction will not answer honestly. How you prevent employees from using a tool no one has approved therefore does not start with control, but with an invitation to report what is already happening. That is a different order than most organizations are used to, and in the ICT sector that order is especially important, because the distrust between development teams and compliance departments is often already present here.
Not all AI use in the ICT sector requires the same attention. A model that summarizes internal documentation is different from a model that co-decides on access rights or that runs as part of a delivered product at a client's site. The classification by role and risk level is therefore not something that happens once, but something that must move along with what a team is building. That is a different dynamic than in sectors with more stable processes, as described in the descriptions of governance in financial services or the energy sector, where AI applications usually remain within a fixed operational structure. In the ICT sector, the application sometimes changes faster than the classification can keep up with, which means the governance structure itself must have room for reassessment, not only for one-time approval.
A risk that takes on its own color in the ICT sector is the use of free or public AI tools for work that is actually confidential: source code, client data, internal architecture, contract terms. A developer who quickly has a piece of code checked by a public model does not think about what happens to that input. How you prevent company data from ending up in a free chat window describes that mechanism, and it is more relevant in this sector than in most others, because the data that leaks out is often not only personal data, but also intellectual property and client code. A governance structure that records nothing about this leaves the risk with the individual employee, while the exposure lies with the organization.
An executive or General Counsel in the ICT sector often already has risk frameworks for information security, software quality and supplier management. AI governance works better if it connects to that existing structure than if it becomes a separate track that no one recognizes. That applies more strongly here than in sectors such as the real estate sector or construction, where AI governance often still starts on a blank sheet. In the ICT sector, a risk language is usually already present; the work is to extend that language without replacing it.
The Responsible AI Scan maps what AI is running in the organization, including what has arisen outside the official list, and links this to a classification by role and risk level. The result is a governance set that connects to the existing structure, not a new framework alongside it. The tool that supports this is still under construction. Those who want to make use of this can sign up for the waiting list; nothing is currently being delivered beyond that registration.
Once it becomes visible which AI applications exist and what risk level belongs to them, the next question follows naturally: which part of the work still done by people is suitable to hand over to those applications. That is a different question than governance, and it is answered by the work scan of FTE TO AI, which calculates per task which part of the work can be taken over by AI.
Vraag maar. Governance begint bij weten wat er draait — ook wat niemand heeft goedgekeurd.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.