Approval process
How an AI deployment gets assessed, decided and documented, without turning into a procedure that creates shadow AI.
Two routes
| Route | When | Duration | Decision |
|---|---|---|---|
| Fast | No personal data, no Annex III, approved tool | days | Business area with a checklist |
| Thorough | Personal data, new provider, Annex III, employee data | weeks | Designated function with legal and data protection |
The fast route matters more. Without it, low-risk cases bypass the procedure too, and the inventory becomes incomplete.
The checklist for the fast route
- Which task, how often, with what expected result?
- Which data actually flows into the input?
- Is the tool approved, and for this kind of data?
- Who checks the output before it leaves the building?
- Who is responsible, by name?
Five questions, one page, one decision. If any answer is "unclear", the case goes to the thorough route.
The thorough route
- 01
Purpose and boundary in writing
What the system is to do and expressly not. That determines the classification.
- 02
Determine role and class
Provider or deployer, class under the AI Act, with reasoning.
- 03
Assess data protection
Legal basis, purpose limitation, processing on behalf, third-country element, impact assessment where required.
- 04
Settle consultation
Works council or staff representation where employees are affected.
- 05
Decide and record
With conditions, a review cycle and named ownership.
The inventory entry
| Field | Content |
|---|---|
| System and version | What exactly, in which build |
| Purpose and boundary | For what, and expressly not for what |
| Role | Provider or deployer, with reasoning |
| Class | Under the AI Act, with reasoning and date |
| Data categories | What is actually processed |
| Legal basis | With a pointer to the balancing test where relevant |
| Provider and contracts | Processing agreement, locations, sub-processors |
| Responsible person | By name |
| Overseeing person | By name, at high risk |
| Conditions | What must hold for the approval to carry |
| Review cycle and date | When to reassess |
That table is simultaneously the answer to a supervisory enquiry. Anyone keeping it has nothing to assemble in an incident.
Triggers for reassessment
- Change of the underlying model, including by the provider without notice.
- Extension of the purpose or of the user group.
- New data categories in the input.
- Change of provider or of a sub-processor.
- An incident or a noticeable drop in quality.
- Expiry of the review cycle.
The first row needs a contractual provision: the provider must be obliged to announce model changes. Without that clause the trigger cannot be noticed.
Folding in shadow AI
- 01
Search rather than ask
Check network logs and expense claims for provider access. That finds more than any survey.
- 02
Amnesty
Whoever reports gets an assessment rather than a sanction. Without that promise nobody reports.
- 03
Decide fast
Rule on reported cases within two weeks, or the amnesty evaporates.
- 04
Offer an alternative
A ban without a replacement only produces better-hidden shadow AI.
Related courses and sources
Fraunhofer IAIS on artificial intelligence
German-language guidance on auditing, certifying and operating AI systems, from applied research.
For German-language audit and certification questions where English sources do not help.
NIST AI RMF Playbook
The practical build-out of the risk framework: concrete suggestions per function on what to do and what to document.
For anyone building an internal risk assessment who wants an outline that has already been thought through.