Are You Governing AI Safely? AI Act Classification, GDPR, Copyright, and Your Internal AI Policy
Most organisations cannot answer a simple question: are you governing AI safely? Not because they do not care, but because they cannot see what AI is running, on what data, under whose ownership. Safe AI governance comes down to four pillars: classifying your systems under the AI Act, reconciling AI with GDPR, solving copyright, and setting an internal policy people actually follow.
The Question Behind the Question
Ask a leadership team whether they are governing AI safely and you usually get a pause. The honest answer is rarely yes or no. It is "we are not entirely sure", because the question hides four harder ones underneath it.
AI governance is not a single control you switch on. It is the discipline of knowing what AI you run, on what data, under whose ownership, against which rules. When that knowledge is missing, every downstream control is a guess.
Four pillars carry the weight. Each maps to a question you should be able to answer with evidence rather than instinct:
- Classification. Which AI systems do you run, and how risky is each one under the AI Act?
- Data protection. How do those systems handle personal data under the GDPR?
- Copyright and IP. What goes into your AI, and who owns what comes out?
- Internal policy. What rules guide the people using AI every day, and do they follow them?
Work through the four and you have a defensible answer. Leave any one blank and that is where your exposure lives.
Pillar 1: Classify Your AI Systems Under the AI Act
You cannot apply the right controls until you know what you are controlling. The AI Act sorts systems into four tiers, and your obligations follow the tier:
- Unacceptable risk. Banned outright, such as social scoring or manipulative systems. These cannot be used at all.
- High risk. Permitted with strict obligations: risk management, data governance, technical documentation, logging, human oversight, and traceability. This covers AI in areas like recruitment, credit, and access to essential services.
- Limited risk. Transparency obligations, for example telling users they are interacting with AI or that content is AI-generated.
- Minimal risk. No specific obligations beyond good practice.
The obligations apply to deployers, not only to the companies that build the models. If you use a high-risk system, the duties around oversight and record-keeping are yours.
The recent AI Omnibus pushed the high-risk deadlines to December 2027 and August 2028, but it did not change the classification itself. The practical first move is unchanged: build a living inventory of every AI system, record its purpose and data sources, and assign each one a risk tier. Everything else in this article depends on having that inventory.
Pillar 2: Reconcile AI with GDPR
The AI Act sits on top of the GDPR; it does not replace it. The moment an AI system touches personal data, every familiar GDPR principle still applies, and AI makes several of them harder to honour.
- Lawful basis and purpose limitation. Data collected for one purpose cannot be repurposed to train or run a model without a fresh basis.
- Data minimisation. Models pull toward more data; the GDPR pulls toward less. Feeding a prompt or a training set more personal data than the task needs is a violation waiting to surface.
- Transparency and data subject rights. People have the right to know how their data is used and to have it corrected or erased, which is difficult once data is absorbed into a model.
- Impact assessments. High-risk processing may require a data protection impact assessment before the system goes live.
The recurring failure point is invisible personally identifiable information in prompts and training data. You cannot protect what you cannot see. Knowing where personal data sits and where it flows is the shared foundation that serves both the GDPR and the AI Act, so the mapping is worth doing once and reusing across both.
Pillar 3: Solve Copyright and IP
Copyright is the pillar most teams overlook, and it cuts two ways: what goes into the AI, and what comes out.
On the input side, training and prompting often involve third-party material. EU copyright law allows text and data mining, but rights holders can opt out, and providers of general-purpose AI models must keep a copyright policy that respects those opt-outs. Since August 2025 those providers must also publish a summary of their training content, using the AI Office template released on 24 July 2025. Even if you only deploy AI rather than build it, that obligation shapes which models you can trust, and pasting proprietary or licensed material into a public tool can breach both third-party rights and your own confidentiality commitments.
On the output side, ownership is uncertain. In the EU, copyright protection generally requires human authorship, so purely machine-generated output may not be protected at all. Output can also reproduce material from training data, creating an infringement risk you inherit. Treat AI output as a draft that needs human review and a clear record of how it was produced.
Copyright failures rarely come from bad intent. They come from not tracking what data entered a system and what the system produced. That is a metadata problem before it is a legal one.
Pillar 4: An Internal AI Policy People Follow
The first three pillars are about systems and data. The fourth is about people, and it is where most governance quietly fails. A policy nobody reads protects nobody.
A usable internal AI policy is short, specific, and enabling. It should answer the questions employees actually have:
- Which tools are approved, and how do I request a new one?
- What data may I enter, and what must never leave our perimeter?
- When is human review required before I act on an AI output?
- Who owns each AI use case, so there is a person accountable, not just a rule?
The instinct to ban AI outright backfires. Prohibition does not stop usage; it pushes it into unsanctioned tools your security team cannot see, the problem we cover in our piece on shadow AI. A policy that enables safe use, backed by governed alternatives, is the only version that holds.
"A policy nobody reads protects nobody. Enable safe use, do not just forbid the unsafe."
Why Governance Needs a Data Foundation
The four pillars look like four separate projects. They are not. Each one rests on the same foundation: knowing your systems, your data, and your ownership.
Classification needs an inventory of AI systems. GDPR compliance needs to know where personal data flows. Copyright control needs a record of what entered a system and what it produced. An internal policy needs assets it can point to and owners it can hold accountable. Build the foundation once and all four pillars stand on it. Skip it and you rebuild the same groundwork four times, inconsistently.
Where Dawiso Fits
Every pillar comes back to the same need: a single, governed record of what you run and what data it touches. That is the foundation Dawiso provides.
The Data Catalog becomes the living inventory of data assets and the AI systems that consume them, the starting point for classification. Interactive Data Lineage traces where data, including personal data, flows end to end, which is what GDPR mapping and copyright tracing both require. Access management and clear ownership turn an internal policy from a document into enforced practice. The AI governance solution ties classification, ownership, and policy to the assets themselves.
For teams putting AI to work, the Context Layer and Model Context Protocol (MCP) support give AI the governed business context it needs, with the access controls and traceability that safe governance depends on. The result is one record that answers all four questions at once.
So, are you governing AI safely? Once you can classify your systems, see where personal data flows, track copyright on both sides, and point employees to a policy they follow, the answer stops being "we are not sure" and becomes "yes, and here is the evidence".