Every AI system that has value for your company touches your most sensitive data. Orders, customers, production processes, financial information, employee data. There's no way around this reality: AI without data is useless, and useful data is almost always sensitive.

The question isn't whether AI accesses your data. The question is how it protects them. At GRAL, data security isn't an additional chapter in the proposal — it's the foundation everything else is built on.

This article isn't a legal guide. It's a practical guide for those who need to make informed decisions about data security in AI contexts.

The Italian and European Regulatory Landscape

Italian companies operate within one of the world's most stringent regulatory frameworks for data protection. This is often perceived as a brake. In reality, it's a competitive advantage — if you know how to navigate it.

GDPR: The Basics Many Ignore

GDPR has been in effect since 2018, but many companies only apply the surface. In the AI context, the implications run deeper than they appear.

Data minimization. GDPR requires that you collect and process only strictly necessary data. This means an AI system can't "take everything and see what's useful." You need precise mapping: what data the model uses, why, for how long.

Right to explanation. If an automated decision has significant impact on a person — loan denial, employee evaluation, medical triage — that person has the right to an understandable explanation. Pure black-box models are problematic in this context.

Data Protection Impact Assessment (DPIA). For high-risk processing — and many AI systems fall into this category — a DPIA is required before starting. It's not just bureaucracy: it's an exercise that forces you to think about risks before creating them.

AI Act: The New Layer

The European AI Act adds another regulatory layer, with a risk-based approach.

High-risk systems. If your AI system operates in areas like human resources, credit, healthcare, critical infrastructure, it's classified as high-risk. This implies specific requirements: technical documentation, data quality management, human oversight, transparency, robustness.

Prohibited systems. Some applications are simply banned: social scoring, subliminal manipulation, mass biometric surveillance. Seems obvious, but boundaries can be blurry — an employee performance monitoring system could approach problematic territory.

Transparency obligations. Users must know when they're interacting with an AI system. If your customer service chatbot is AI-powered, it must disclose this.

The Italian Data Protection Authority

Italy's Garante per la Protezione dei Dati Personali is among the most active in Europe. It has already taken strong positions on AI systems — the 2023 ChatGPT case being the most well-known example. For Italian companies, this means compliance isn't theoretical: it gets verified and sanctioned.

Concrete (Not Theoretical) Risks

Beyond regulatory compliance, there are operational risks every company must evaluate.

Data Leakage Through Models

Language models and other AI models can memorize fragments of training data. If you train a model on your business data and that model is then shared or exposed, parts of your data can be extracted.

How to mitigate: use models that run on your infrastructure, not shared clouds. If you use third-party APIs, verify their data usage policies — is your data being used to train the provider's model? In many cases, the answer is yes, unless you explicitly opt out.

Unauthorized Access

An AI system accessing sensitive data is a target. If the AI's API isn't adequately protected, an attacker could use it to extract information — not by hacking the database, but by asking the model the right questions.

How to mitigate: strong authentication, granular authorization (not everyone sees everything), logging of all access, rate limiting to prevent mass extraction.

Decisions Based on Erroneous Data

If the training dataset contains errors, biases, or outdated data, the model will make wrong decisions with high confidence. A CV screening system trained on historical data with gender bias will perpetuate that bias.

How to mitigate: regular dataset audits, testing for known biases, continuous monitoring of model decisions to identify anomalous patterns.

Vendor Dependency

If your AI vendor has access to your data and one day fails, gets acquired, or changes contract terms, is your data safe? Can you take it away? Is the model trained on your data yours or the vendor's?

How to mitigate: clear contractual clauses on data and model ownership, exit strategy defined before starting, independent backups.

Security Architectures

Not all AI architectures offer the same level of protection. The architectural choice is a security choice.

Public Cloud with Third-Party APIs

How it works: your data is sent to an external API (OpenAI, Google, etc.) for processing.

Pros: fast to implement, low initial costs. Cons: data leaves your perimeter. You're subject to the provider's policies. In many cases, not GDPR-compatible for sensitive data without significant additional measures.

When it's acceptable: for non-sensitive data, rapid prototyping, internal use cases with limited risk.

Private Cloud or Dedicated VPC

How it works: models run on a cloud instance dedicated to your company. Data doesn't leave your Virtual Private Cloud.

Pros: greater control, simpler compliance, separation from other customers' data. Cons: higher infrastructure costs, management complexity.

When it makes sense: for most enterprise projects with sensitive data. It's the most common compromise between security and practicality.

On-Premise

How it works: hardware and software in your physical facility. No data leaves the building.

Pros: maximum control, no cloud provider dependency, simplified compliance for ultra-regulated sectors. Cons: significant hardware costs, need for internal management expertise, more complex scaling.

When it makes sense: for sectors with extreme security requirements (defense, healthcare, critical infrastructure) or where regulation mandates it.

GRAL supports all three architectures. The choice depends on the client's context, not our preference.

The Pre-Project Security Checklist

Before starting any AI project that touches business data, GRAL recommends completing this checklist.

Data mapping:

  • What data will the AI system use?
  • Does it contain personal data (GDPR)?
  • What is the security classification of this data?
  • Where does it physically reside today?

Architecture:

  • Where will models run? (on-premise, private cloud, public cloud)
  • Will data travel in plaintext or encrypted?
  • Who will have access to the system? With what authorization levels?
  • How are access logs managed?

Compliance:

  • Is a DPIA needed?
  • Does the system fall under AI Act high-risk categories?
  • Has the company DPO been involved?
  • Are there sector-specific regulatory requirements?

Contractual:

  • Who owns the processed data?
  • Who owns the trained model?
  • What happens to data at contract end?
  • Do audit clauses exist?
  • What is the procedure in case of data breach?

Operational:

  • Who monitors system security in production?
  • What is the incident response plan?
  • How are security updates managed?
  • How frequently are security audits conducted?

The Cost of Non-Security

GDPR fines can reach 4% of global revenue. AI Act penalties will be even heavier for the most serious violations. But the real cost of a security incident isn't the fine — it's the loss of trust from customers, partners, and employees.

An Italian company that suffers a data breach related to an AI system doesn't just lose money. It loses credibility in a market where trust is everything.

Investing in security isn't a cost. It's the minimum condition for doing AI seriously. GRAL treats it as such in every project, because any AI system that isn't secure isn't an AI system worth building.