Skip to main content

Are You Governing AI Safely? AI Act Classification, GDPR, Copyright, and Your Internal AI Policy

Samuel Nagy
Samuel Nagy
VP of Strategic Growth

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.

Four Pillars of Safe AI Governance FOUR PILLARS OF SAFE AI GOVERNANCE 1 Classify Risk tiers under the AI Act What do you run? 2 Protect data Reconcile AI with the GDPR On what data? 3 Copyright IP on input and output Who owns it? 4 Internal policy Rules people actually follow Who follows it?
Click to enlarge

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.

Pillars on a Shared Data Foundation FOUR PILLARS, ONE FOUNDATION Classify AI Act tiers Protect data GDPR Copyright Input and output Internal policy People and rules GOVERNED METADATA FOUNDATION AI system inventory · data lineage · ownership · data classification
Click to enlarge

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".

FAQ

What does it mean to govern AI safely?
Governing AI safely means you can answer four questions with evidence: which AI systems you run and how risky they are, how those systems handle personal data, how you manage copyright on both the input and the output side, and what internal policy guides employee use. If any of the four is a blank, that is where the risk sits.
Do we need to comply with the AI Act if we only use AI tools, not build them?
Yes. The AI Act applies to deployers, not only providers. If you use a high-risk AI system, you carry obligations around human oversight, monitoring, and keeping records. The first step is the same for everyone: classify each system by its risk tier so you know which rules apply.
Where do AI governance and GDPR overlap?
Wherever AI touches personal data. You still need a lawful basis, purpose limitation, data minimisation, and transparency. Prompts and training data that contain personal data fall under GDPR, and high-risk processing may require a data protection impact assessment. Tracking where personal data flows serves both regimes at once.
Who owns the output of a generative AI tool?
In the EU, copyright protection generally requires human authorship, so purely AI-generated output may not be protected, and it may also reproduce material from training data. Treat outputs as needing human review, and never paste proprietary or third-party material into public AI tools without checking the terms and your own IP obligations.
What belongs in an internal AI policy?
A usable AI policy names which tools are approved, what data may and may not be entered, when human review is required, who owns each AI use case, and how to request a new tool. It should enable safe use rather than ban AI outright, because blanket bans push usage into the shadows.
Next step

Trusted data starts here.

Pick one problem. We map the data first, fix what's broken, then help your team trust every number.

Take the product tour
© Dawiso s.r.o. All rights reserved