re-ai-gov Join the waiting list

Kennisbank

What a General Counsel needs to know about AI risk

A General Counsel is not judged on what goes wrong with AI. They are judged at the moment it becomes clear that the organization could not demonstrate that it knew, or worse, that it could have known and did nothing. That is the difference between an incident and a failure. The first happens to an organization. The second is held against it.

The question you ask is not legal, it is factual

The legal question — what is permitted, what is required, which deadline applies — is important, but it comes after another question. That question is: what are we actually using. Not what has been purchased, not what is on IT's vendor list, but what people in practice are letting help decide, help draft, or help assess. Without an answer to that question, every piece of legal advice is advice about a situation you do not know.

That makes the position of the General Counsel uncomfortable. You are expected to assess risks based on an inventory that usually does not exist, or that consists of what has been approved — which by definition is not what someone started using without permission.

The answer you do not accept

"We don't need an AI policy because we don't have AI" is not an answer that holds up. It is an assumption, and assumptions are exactly what a regulator, a judge, or a journalist will not accept after the fact. Nor do you accept a list of approved tools as a complete picture: that list says something about what has been purchased, nothing about what is being used.

What you do need is a distinction between types of use. A language model that summarizes internal notes carries a different risk than a system that factors into a hiring decision or a credit assessment. Without classification by role and risk level, every discussion about AI risk is a discussion in the abstract, and abstract discussions do not lead to defensible positions.

What is really going on, you will not find in a system

Shadow AI — the use that arises outside of any approval — is not something an IT department detects with a network scan. People use AI on their own laptop, in their own browser, with their own account. That use leaves few traces in a system that is not looking for it.

What does work is asking. But only if the answer has no consequences for whoever gives it. Someone who uses AI to prepare a draft contract, or to have a risk analysis summarized, will not report it if reporting it could lead to a reprimand. The inventory you need only comes about if asking the question does not amount to holding people accountable.

That is a precarious balance for a legal function. You are used to assessing risk based on what could go wrong. Here you must first ensure that people dare to tell you what they are already doing, before you can assess whether that is a risk.

Demonstrability is the real work

The core of your position is not preventing every risk — that is not realistic and is not expected of you either. The core is demonstrability: can you show that the organization knew what it was using, had assessed what risk was attached to it, and had a structure in place to act on that. That is a different mandate than controlling outcomes. It is controlling the process by which outcomes are monitored.

That demonstrability does not need to rest on a new framework. Most organizations already have a risk structure — for financial risk, operational risk, compliance. AI risk should land within that structure, not stand next to it as a separate track that nobody knows and nobody maintains. A governance set that connects to what already exists gets used. A separate structure gets forgotten after the first quarter.

Where this affects you and where it does not

This position describes the mechanism: taking inventory, classifying, connecting to existing structure, making it demonstrable. It does not describe which laws or regulations apply to your organization, which deadlines apply, or which obligation takes effect at which moment. That content changes, gets supplemented, gets explained by those who specialize in it. What matters here is the structure within which that content can land the moment you need it.

The questions you ask overlap with what a risk manager needs to know about AI risk and with the position of a compliance officer who must be able to demonstrate AI use. The executive who bears accountability to the supervisory board also benefits from the same inventory on which you base your own assessment — it is the same set of facts, viewed from a different responsibility.

The tool is under construction

The Responsible AI Scan that carries out this mechanism — taking inventory, classifying, connecting to the existing risk structure — is under development. Anyone who needs this now can sign up for the waiting list. There is no service to deliver yet; there is a direction in which this is being built, and this is that direction.

From risk inventory to work distribution

Once it is clear which AI is running and what risk is attached to it, another question follows, one that lies outside your own responsibility but connects to it: what part of the underlying work is that AI actually taking over. That is a question that is not about risk, but about the organization of work, and it is answered by the work scan from FTE TO AI, which calculates per task which part qualifies for takeover.

Andrewde assistent van de Responsible AI Scan

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.