AI governance and compliance
The AI Act and AI governance: what companies need to do now
AI governance means having three things under control: knowing which AI is actually running in the organization, classifying it by risk, and keeping evidence for every requirement that the controls genuinely hold. The AI Act makes exactly this a duty. And it sharpens a question that many organizations still leave open: a policy in a document is not yet proof that it holds in operation.
- Maintain a complete AI inventory, including the tools used unofficially (shadow AI).
- Assign every system to a risk class, because the concrete obligations depend on it.
- For high-risk applications, document risk management, data quality, logging, and human oversight.
- Meet transparency obligations, such as labeling AI-generated content and disclosing direct interaction.
- Build AI literacy in the team, because the AI Act explicitly requires it.
- Back every governance control with dependable evidence, not just a policy on paper.
What the AI Act requires
The AI Act, the European regulation on artificial intelligence (Regulation (EU) 2024/1689), is the first comprehensive legal framework for AI in the EU. Its guiding principle is risk-based: not every application is treated the same way, but regulated more or less strictly depending on the potential harm. The regulation applies in stages, with different dates of application for prohibitions, general-purpose models, and high-risk systems. The specific timelines, and whether and how your company is affected, are a legal question to be settled case by case. For governance practice, one thing matters above all: anyone who develops or deploys AI must in future be able to document and demonstrate what the systems do, which risks they carry, and how those risks are kept under control.
For most companies this means no panic, but structure. The AI Act does not require a one-off action, but an ongoing process: capture AI, classify it, control it, evidence it, keep it current. That is precisely AI governance.
The risk classes
The AI Act sorts AI systems into risk tiers. The classification decides the obligations, which is why it is the pivot of any governance. The following overview is a simplified orientation, not a definitive legal classification.
| Risk class | What falls under it and what applies |
|---|---|
| Unacceptable risk | Practices considered a threat to fundamental rights, such as certain forms of social scoring or manipulative influence. These applications are prohibited in principle. |
| High risk | Systems in sensitive areas such as recruitment, credit scoring, critical infrastructure, or certain product components. The strictest obligations apply here: risk management, data quality, technical documentation, logging, human oversight, and robust cybersecurity. |
| Limited risk (transparency) | Systems with direct user interaction or generated content, such as chatbots or AI-generated media. The core obligation is transparency: people must be able to recognize that they are interacting with AI or that a piece of content is AI-generated. |
| Minimal risk | The majority of everyday applications, such as spam filters. No specific legal obligations, voluntary self-commitment possible. |
| General-purpose AI models | Large foundation models carry their own obligations, among them technical documentation and transparency, with additional requirements where there is systemic risk. |
The practical catch: you can only classify a system if you even know that it exists. And that is exactly where the shadow-AI problem begins.
Making shadow AI visible
Shadow AI is the use of AI tools without the knowledge or approval of the organization: the department that runs an AI assistant inside a process, the team that connects an external model to internal data, the developer who wires an AI agent to production systems. Each of these tools is an AI system in the governance sense, but none appears in an inventory. What is not in the inventory cannot be assigned to a risk class, cannot be subjected to a control, and cannot be evidenced in any record.
Making shadow AI visible is therefore the first hard step of any AI governance. It succeeds through a combination of organizational and technical discovery:
- A structured stocktake across departments: which AI-assisted tools are in use, for what purpose, with what data?
- Technical visibility, for example through outbound connections, the APIs in use, and interfaces to AI services and model endpoints.
- Particular attention to autonomous components: AI agents and the tools they connect, for example over the Model Context Protocol, widen the attack and governance surface considerably.
- A simple, workable reporting path, so that new AI use enters the inventory instead of drifting into the shadows.
AI governance step by step
Governance becomes tangible when you set it up as a repeatable process rather than a one-off project. A proven sequence:
Step 1: Set responsibility and policy
Name a clear owner, adopt an AI policy that governs permitted and prohibited use, and embed the AI literacy the AI Act calls for in the team. Without an owner, governance stays on paper.
Step 2: Build the AI inventory
Capture all AI systems, official and unofficial alike. Per entry: purpose, data basis, provider, interfaces, owner. Actively hunt for shadow AI rather than waiting for it to surface.
Step 3: Classify the risk
Assign every system to a risk class and derive the resulting obligations. High-risk applications get the full depth, minimal applications only the light framework.
Step 4: Implement controls
Translate the obligations into concrete measures: risk management, data quality and documentation, logging, human oversight, technical robustness and cybersecurity, transparency toward users.
Step 5: Keep and maintain evidence
Collect proof for every requirement, during ongoing operation, not just shortly before an assessment. Models, prompts, connections, and risks change, so governance belongs in a recurring rhythm.
Why governance without proof is worthless
Here is the point where many governance programs turn thin. Writing a policy, maintaining an inventory, and naming controls produces a folder full of assurances. But an assurance is not proof. For high-risk systems the AI Act explicitly calls for robust cybersecurity and controlled technical risks, and those very properties cannot be substantiated by self-declaration.
The difference shows up in the technical controls. You can state in a policy that your AI agent only accesses approved tools, that a model does not leak internal secrets, that input from a foreign data source is not interpreted as an instruction. Whether these statements actually hold in operation only becomes clear when you challenge them deliberately. A pure pattern scanner finds the known-bad, but many risks of AI systems and their connections lie in the design of permissions and trust boundaries, not in known code patterns.
Dependable AI governance therefore needs both: the organizational layer that translates obligations into controls, and the technical layer that backs every critical claim with an executed piece of evidence rather than merely asserting it. In the end, governance is only as good as the proof that the controls hold. It is precisely this discipline, testing every load-bearing property before the assurance, that separates auditable governance from a collection of good intentions.
Does your AI governance hold up to proof?
We translate the requirements of the AI Act into concrete controls and back the technically load-bearing properties with a proof of concept per finding, instead of an assumption.
See Compliance ReadinessCyberSec42 is an independent technical security assessment, not an accredited certification body and not legal advice. The legal classification under the AI Act is the responsibility of your legal counsel.
Frequently asked questions
What does the AI Act require of companies?
The AI Act, the EU regulation on artificial intelligence, regulates AI on a risk basis. Companies must capture their AI systems, assign them to a risk class, and meet the obligations attached to it, for high-risk systems for example risk management, data quality, documentation, human oversight, and cybersecurity. The concrete exposure and the timelines are a legal question for the individual case.
Which risk classes does the AI Act define?
Simplified: unacceptable risk (prohibited in principle), high risk (strictest obligations), limited risk with transparency obligations (such as chatbots and AI-generated content), and minimal risk (no specific obligations). General-purpose AI models have their own, separate obligations.
What is shadow AI and why is it a problem?
Shadow AI is the use of AI tools without the knowledge or approval of the organization. It is a governance problem because a system that appears in no inventory cannot be assigned to a risk class, cannot be subjected to a control, and cannot be evidenced in any record. Visibility is therefore the first step of any AI governance.
What does an AI governance process look like?
In five steps: set responsibility and policy, build an AI inventory, classify every system by risk, translate the obligations into concrete controls, and keep evidence for every requirement current on an ongoing basis. Governance is a recurring process, not a one-off project.
Is a documented policy enough for AI governance?
No. A policy describes what should apply, it does not prove that it holds in operation. The technical controls in particular, such as an AI agent only using approved tools or no internal secrets leaking out, can only be substantiated through targeted testing with an executed piece of evidence. Governance is only as good as the proof that the controls hold.