# Shadow AI and Corporate Data Security: KVKK, GDPR and Protecting Sensitive Data in AI

**URL:** https://securesys.com.tr/en/learning/software-and-ai-security/what-is-shadow-ai-corporate-data-security-kvkk-gdpr-risks

![Shadow AI and Corporate Data Security: KVKK, GDPR and Protecting Sensitive Data in AI](/images/bilgi-merkezi/covers/cover-yzguv-07.webp)

### Introduction: Employees Are Using AI, but Do Organisations Know What Data Is Being Shared?

Artificial intelligence technologies are rapidly changing the way organisations work.

Software developers use AI assistants to generate code.

Sales teams prepare proposal texts.

Human resources staff evaluate CVs.

Finance departments have spreadsheets analysed.

Legal teams summarise contracts.

Marketing teams create content.

IT staff ask AI to interpret error logs.

All of these use cases can deliver significant productivity gains.

From a corporate security perspective, however, a critical question arises:

#### Is it known what information employees send to AI services?

For example, a software developer trying to resolve a problem encountered in the production environment may send part of the source code to an external AI service.

A sales representative may upload a contract file to have a customer proposal summarised.

A human resources employee may transfer personal data to an AI application in order to compare candidate CVs.

A system administrator may share application logs for error analysis.

These actions may have been taken simply to make employees' work easier.

However, the shared content may include personal data, trade secrets, access credentials or confidential corporate documents.

Moreover, the organisation may never have assessed which data the AI service stores, for what purposes it processes that data, or in which countries it does so.

This kind of uncontrolled usage is what the concept of **Shadow AI** describes.

Shadow AI is not merely employees using a new technology.

It is a governance problem that must be assessed in terms of corporate visibility, data security, access control, supplier management and regulatory compliance.

In this article, we examine Shadow AI risks, realistic corporate scenarios, and the technical and administrative controls that make secure AI use possible.

### \1. What Is Shadow AI?

Shadow AI refers to AI applications and AI-assisted business processes that are used outside the organisation's approval, visibility or security controls.

This usage can take different forms.

For example, an employee may upload a company document to an AI service that has not been approved by the organisation.

A software team may start using a code assistant without an information security assessment having been carried out.

A department may purchase an AI-based SaaS service from its own budget.

An employee may use an AI application on a personal account for corporate work.

What these scenarios have in common is that AI usage takes place outside the organisation's security and governance processes.

#### The relationship between Shadow AI and Shadow IT

Shadow IT refers to systems and applications that are used without the knowledge or approval of the IT department.

Shadow AI is the AI-specific dimension of this problem.

The key difference is that AI applications do not merely store or transfer data; they analyse the content sent to them, transform it and produce new outputs.

This can make data security assessment more complex.

### \2. Why Is Shadow AI Becoming So Widespread?

One of the main reasons for the spread of Shadow AI is that access to AI tools has become so easy.

An employee can often reach an AI service through a browser without installing any new application.

Some services offer free usage.

Others are integrated into existing office or development tools.

As a result, AI usage can spread faster than traditional software procurement processes can keep up with.

#### Productivity expectations

Employees want to complete routine work in less time.

For example, summarising a long document or having a complex Excel formula explained can save a significant amount of time.

#### Lack of a corporate alternative

The organisation may not have offered its employees an approved AI solution.

In that case, employees may turn to individual solutions.

#### Lack of security awareness

An employee may not fully appreciate that sending a text to an AI service amounts to a data transfer.

#### Unclear usage policies

The organisation may not have a clear policy on AI usage.

#### Invisible integrations

AI features may have been added to existing SaaS applications.

An employee may not know which AI infrastructure the application they use is passing data to.

For this reason, Shadow AI cannot be explained by employee behaviour alone.

Corporate technology management and security policies are also important parts of the problem.

### \3. What Are the Security Risks of Shadow AI?

Shadow AI risks can be assessed in different categories.

| Risk category | Potential security impact |
| --- | --- |
| Sharing of sensitive data | Trade secrets or confidential information being transferred to an external service |
| Personal data processing | Risk of breaching KVKK (Turkish Personal Data Protection Law) and GDPR obligations |
| Sharing of source code | Intellectual property and software security risks |
| Sharing of credentials | Exposure of API keys or access credentials |
| Supplier uncertainty | Data processing and retention conditions being unknown |
| Unauthorised integration | Uncontrolled access to corporate systems |
| Incorrect AI outputs | Wrong business decisions or security errors |
| Lack of auditability | Inability to monitor data flows and incidents |

Not all of these risks are at the same level.

For example, rewriting a publicly available product description with AI may be low risk.

However, uploading an entire customer database to a personal AI account can have far more serious consequences.

For this reason, a risk-based approach is necessary in Shadow AI management.

### \4. Where Does the Data Sent to AI Go?

This is one of the questions corporate users ask most often.

Content sent to an AI service can be processed in different ways, depending on the architecture of the product used and the contractual terms.

For example, the data:

- May be processed for model inference.
- May be retained in service logs for certain periods.
- May be passed through security and abuse-prevention controls.
- May be used in service improvement processes, depending on product settings and contractual terms.
- May be processed by sub-processors.
- May be transferred to infrastructure in different geographical regions.

However, it cannot be said that all AI providers have the same data processing policy.

The data usage terms of individual, enterprise and API services can differ.

For this reason, the security assessment must be carried out per provider and per product.

#### Questions organisations should examine

For what purposes is the data processed?

For how long is it retained?

Is it used for model training or service improvement?

Which sub-processors are involved?

In which countries is the data processed?

How are deletion requests handled?

Are audit logs provided?

Is there an enterprise data protection agreement in place?

If these questions are not answered, transferring sensitive data to external AI services may prevent a proper risk assessment from being carried out.

### \5. Sharing Source Code with AI Services

Software development teams can make extensive use of AI technologies.

Code explanation.

Bug analysis.

Test case generation.

Refactoring.

Documentation.

Security recommendations.

These activities can deliver significant productivity gains.

However, source code may contain the organisation's intellectual property and technical architecture.

For example, source code may contain:

Business logic.

API endpoint information.

Database structure.

Authentication flows.

Integration details.

System configurations.

may all be present.

In some cases, developers may also share access keys or connection details by mistake.

#### Security approach

A source code sharing policy should be established.

Approved code assistants should be designated.

Repository access should be restricted.

Secret scanning should be applied.

Corporate data processing terms should be assessed.

Where necessary, an in-house model or a controlled AI Gateway architecture can be preferred.

**Sending source code to AI is not merely a software development preference; it is a data and intellectual property security decision.**

### \6. API Key and Credential Leakage

One of the critical risks in Shadow AI usage is the sharing of credentials.

For example, a system administrator may send an error message to an AI service in order to have an API error analysed.

However, the error message may contain an access token.

Similarly, a software developer sharing a configuration file may not notice the API key inside it.

#### Examples of risky data

API key.

Access token.

Refresh token.

Database password.

Private key.

Cloud credential.

Service account details.

Sending this data to external services can create situations that need to be treated as security incidents.

#### Protection approach

Secret scanning should be used.

Sensitive fields should be masked before sharing wherever possible.

Including credentials in prompts should be prevented.

In the event of suspicious sharing, the relevant credentials should be revoked and renewed.

Access logs should be reviewed.

### \7. Transferring Customer Data to AI

Sales, support and operations teams may use AI tools together with customer information.

For example:

Customer contracts.

Proposal files.

Order records.

Support tickets.

Customer emails.

These documents may contain personal data, trade secrets or information covered by contractual confidentiality obligations.

#### Example scenario

A sales representative wants to prepare a summary for a customer meeting.

To do so, they upload the customer's contract to a personal AI account.

However, the organisation has no data processing agreement with this service.

In which countries the data is processed has not been assessed.

In this situation, even if no technical data leak occurs, a risk arises in terms of uncontrolled data transfer and regulatory compliance.

#### Security approach

Customer data should be classified.

The types of data that may be shared should be clearly defined.

Approved services should be used.

Contractual obligations should be checked.

Unnecessary personal and commercial information should be removed.

### \8. Shadow AI Risks in Human Resources

Human resources departments may use AI tools for different purposes.

For example:

CV analysis.

Drafting job advertisements.

Candidate comparison.

Performance reports.

Training planning.

These activities may involve the processing of personal data.

In particular, candidate CVs may contain information such as contact details, educational background and work experience.

Some documents may also contain more sensitive categories of data.

#### Risks

Unauthorised transfer of personal data.

Sharing more data than necessary.

Unclear retention periods.

Incorrect or discriminatory evaluation results.

Insufficient human oversight.

#### Protection approach

The purpose of data processing should be clearly defined.

Unnecessary personal data should not be shared.

An appropriate legal basis for processing should be assessed.

Automated decision-making processes should be reviewed separately.

Appropriate human review should be ensured for critical human resources decisions.

### \9. Shadow AI in Finance and Accounting Departments

Finance teams can use AI for reporting and analysis.

For example, an employee may upload financial statements to have a period-on-period comparison produced.

However, these statements may contain the organisation's undisclosed financial information.

#### Potential risks

Transfer of trade secrets.

Exposure of customer and supplier information.

Sharing of bank account details.

Incorrect financial analysis.

Unauthorised data retention.

For this reason, dedicated controls should be established for the sharing of financial data.

In particular, financial information that has not yet been disclosed and critical payment data should be treated with a high degree of sensitivity.

### \10. Shadow AI and KVKK

In Türkiye, Law No. 6698 on the Protection of Personal Data is important for the protection of personal data.

Transferring personal data to AI applications may, under the relevant conditions, constitute a personal data processing activity.

Organisations therefore need to assess their data processing activities under KVKK.

#### Key areas of assessment

**Compliance with the law and rules of good faith:** Personal data must be processed within an appropriate legal framework.

**Specific, explicit and legitimate purpose:** The purpose of data processing must be defined.

**Data minimisation:** Data that is not necessary for the purpose of processing must not be used.

**Retention period:** Data must be retained only for the necessary period.

**Security measures:** Appropriate technical and administrative measures must be applied.

**Obligation to inform:** Data subjects must be given the required information.

**Transfer abroad:** For transfers of personal data abroad, the relevant provisions of KVKK and valid transfer mechanisms must be assessed.

#### An important legal distinction

Using an AI service does not automatically mean a KVKK violation.

However, if personal data is being processed, a legal basis for processing, data security obligations and, where applicable, the conditions for transfer abroad must be met.

Furthermore, explicit consent is not required for every data processing activity.

The appropriate legal basis must be determined according to the specific processing activity.

### \11. Shadow AI and GDPR

The GDPR, the European Union's General Data Protection Regulation, sets out significant obligations for personal data processing activities.

The applicability of the GDPR is not determined solely by the country in which the company is located.

The nature of the data processing activity and the territorial scope conditions of the GDPR must be taken into account.

#### Areas to be assessed

Legal basis for processing.

Transparency.

Purpose limitation.

Data minimisation.

Storage limitation.

Security.

Data processing agreements.

International data transfers.

Data subject rights.

Data protection impact assessment where required.

#### Example

If the personal data of a European customer is sent to an external AI service without an appropriate assessment, a risk may arise under the GDPR.

However, the obligations that apply must be determined according to the structure of the service, the roles of the parties and the data processing conditions.

### \12. Data Controller and Data Processor Roles in AI

In AI services, the data protection responsibilities of the parties are important.

An organisation may use an AI service in its own business processes.

The service provider, in turn, may carry out certain data processing activities on behalf of the organisation.

However, the legal roles of the parties must be assessed not according to the titles used in the contract alone, but according to the actual data processing activities.

#### Questions to be examined

Who determines the purposes of data processing?

Who determines the means of processing?

Does the service provider use the data for its own purposes?

Are there sub-processors?

How are data retention and deletion processes managed?

These questions are an important part of supplier assessment.

### \13. Transferring Data Abroad in AI

An AI service may use infrastructure in different countries.

For this reason, the geographical regions in which the data is processed matter.

However, the fact that a service belongs to a foreign company does not by itself prove that data is transferred abroad in every case.

The actual data flow and processing architecture must be examined.

#### Security and compliance approach

A data flow map should be created.

The service provider's processing regions should be identified.

Sub-processors should be assessed.

Valid transfer mechanisms should be reviewed.

Contractual and technical measures should be applied.

Particularly in enterprise AI projects involving personal data, the data transfer architecture should be assessed at the design stage.

### \14. What Is AI DLP?

AI DLP is a Data Loss Prevention approach that aims to control data transfers to AI applications from the standpoint of sensitive information security.

Traditional DLP systems try to reduce data leakage through channels such as email, the web, file transfer and endpoints.

AI DLP can be extended to cover AI usage scenarios as well.

#### What data can AI DLP control?

Personal data.

Financial information.

Source code.

API keys.

Credentials.

Customer data.

Content that qualifies as a trade secret.

However, the success of data detection depends on the technology used, the rules and the data format.

For this reason, false positive and false negative results must be taken into account.

### \15. How Does AI DLP Work?

AI DLP can be applied at different control points.

For example, when an employee wants to send text to an AI service, the content can be evaluated against certain rules.

If sensitive data is detected, different actions can be taken under the policy.

#### Possible policy decisions

Allowing the processing.

Warning the user.

Masking sensitive fields.

Blocking the transfer.

Requesting manager approval.

Creating an incident record.

These decisions should be determined according to data classification and the organisation's risk appetite.

For example, sharing a publicly available product description can be allowed freely.

However, sending an entire customer database to an external service can be blocked.

### \16. What Is Data Masking?

Data masking is the concealing or altering of certain fields in order to reduce the direct sharing of sensitive information.

For example, when a customer support record is being analysed, the customer's name, telephone number or identity details may not be necessary for the purpose of processing.

These fields can be transformed using masking.

#### Example

**Original content:**

Müşteri: Ayşe Demir

Telefon: 05XX XXX XX XX

Talep: Sipariş teslimatı gecikti.

**Masked content:**

Müşteri: [MÜŞTERİ_001]

Telefon: [TELEFON]

Talep: Sipariş teslimatı gecikti.

This approach can reduce the transfer of information that the model does not need in order to perform its task.

However, masking does not mean anonymisation in every case.

In particular, data protection obligations may continue to apply in the case of reversible masking and pseudonymisation.

### \17. Tokenization and Pseudonymization

Tokenization is an approach in which sensitive data is replaced with specific representative values.

Pseudonymization is the processing of personal data in such a way that it becomes harder to attribute it to a specific person without the use of additional information.

These methods can be useful in AI data security.

For example, a reference ID can be used instead of a customer's name.

The model can analyse the support request without needing the real identity details.

#### Security requirements

Mapping information must be protected.

Token management must be carried out securely.

Unauthorised re-identification must be prevented.

The data lifecycle must be managed.

These methods can be considered particularly for limiting the transfer of personal data to external models.

### \18. How Is Shadow AI Detected?

The first step in Shadow AI management is achieving visibility.

If an organisation does not know which AI services are being used, it may struggle to enforce its security policies.

#### Detection methods

**Web and DNS visibility:** Connections to AI services can be assessed.

**Secure Web Gateway:** Web access can be monitored according to security policies.

**CASB:** Visibility into the use of cloud applications can be provided.

**SASE/SSE:** Where the architecture allows, cloud and web access controls can be applied.

**Endpoint security:** Application usage on managed devices can be assessed.

**SaaS integration inventory:** Authorised third-party applications can be reviewed.

**Corporate surveys and declarations:** The AI tools used by departments can be identified.

#### An important limitation

Seeing access to an AI service in network traffic does not mean that all of the content sent is known.

Encrypted traffic, the use of personal devices and application architectures can limit visibility.

For this reason, technical controls must be supported by administrative processes.

### \19. How Is a Shadow AI Inventory Built?

A corporate AI inventory should not consist solely of a list of the services in use.

For each use case, there should be information that supports risk assessment.

#### Recommended inventory fields

Application name.

Service provider.

Using department.

Business purpose.

Data types.

Whether personal data is processed.

Sensitivity level of the data.

Integrations.

Data processing region.

Contract status.

Security assessment.

Approval status.

Responsible person or team.

This information must be updated regularly.

This is because the features and data processing terms of AI services can change over time.

### \20. Shadow AI Risk Classification

Applying the same security policy to all AI use cases may not be efficient.

For this reason, risk-based classification is recommended.

#### Low risk

Rewriting publicly available content.

Explaining general technical concepts.

Preparing sample texts that contain no confidential data.

#### Medium risk

Analysing internal corporate documents.

Using information about internal processes.

Processing non-sensitive customer data.

#### High risk

Transferring documents containing personal data.

Sharing confidential source code.

Processing customer contracts in an external service.

#### Critical risk

Sharing credentials.

Large-scale transfer of sensitive data.

Unauthorised financial transaction integrations.

Uncontrolled agent permissions on critical systems.

This classification is an example.

The actual risk level must be determined according to the type of data, the processing conditions and the potential impact.

### \21. Corporate AI Usage Policy

To reduce Shadow AI risks, a clear and enforceable AI usage policy should be established.

This policy should not consist solely of prohibitions.

It should explain in an understandable way which tools employees may use and for which purposes.

#### Policy scope

Approved AI services.

Permitted use cases.

Types of data that must not be shared.

Rules for processing personal data.

Conditions for sharing source code.

Requirements for external integrations.

Actions requiring human approval.

Incident reporting processes.

#### Example policy statement

“Employees may not transfer customer data, personal data, confidential source code, access credentials or documents subject to the organisation's confidentiality classification to AI services that have not been approved by the organisation.”

However, for this rule to be enforceable, employees must also be offered secure alternatives.

### \22. Is Banning AI Entirely the Solution?

Some organisations may consider blocking all AI services in order to reduce Shadow AI risk.

This approach may be appropriate for certain high-risk environments.

However, it is not a sufficient solution on its own for every organisation.

This is because employees' need to use AI may persist.

Uncontrolled use of personal devices or accounts may emerge.

A loss of productivity may occur.

A more balanced approach is therefore to enable controlled use according to risk level.

#### Recommended model

Approved services are designated.

Data classification is carried out.

The transfer of sensitive data is controlled.

An approval mechanism is applied for critical operations.

Usage logs are kept appropriately.

Awareness training is provided to employees.

This approach can provide a more sustainable balance between security and productivity.

### \23. What Is an AI Gateway and How Is It Used in Shadow AI Management?

An AI Gateway is a security and integration layer that can be used to manage communication between AI applications and model services under centralised policies.

Depending on the organisation's architecture and product capabilities, it can offer different controls.

For example:

Model access management.

Sensitive data control.

Prompt security policies.

Data masking.

Usage logs.

Service-based access rules.

Certain Agent and Tool Calling controls.

#### Example scenario

An organisation ensures that its employees use approved AI models through a central gateway.

When an employee wants to have a customer report analysed, the data is passed through certain security checks.

If sensitive fields are detected, masking or blocking can be applied under the policy.

This approach is beneficial for data security.

However, it should not be assumed that all employee AI usage will automatically pass through this gateway.

Out-of-scope applications and alternative access paths must be managed separately.

### \24. Bastiyon AI Gateway and Corporate AI Controls

SECURESYS's Bastiyon AI Gateway approach focuses on establishing centralised security and governance controls for corporate AI usage.

In this context, depending on the use case and integration architecture, the following areas can be assessed:

**Sensitive data masking:** Protecting certain sensitive fields in content to be passed to model services.

**Prompt Injection and Jailbreak controls:** Assessing AI interactions against security policies.

**Shadow AI governance:** Addressing corporate AI usage within the scope of visibility and policy management.

**Agent and Tool Calling control:** Managing the specific operational permissions of AI agents.

**Approval mechanisms:** Supporting additional review processes in critical use cases.

**Audit logs:** Providing traceability of AI interactions.

**In-house deployment:** Assessing on-premises deployment options in suitable architectures.

The effectiveness of these controls depends on the product version used, the scope of integration and the organisation's security architecture.

An AI Gateway should be treated not as a replacement for existing security mechanisms such as access control, DLP, endpoint security and data governance, but as a layer that supports them.

### \25. Does On-Premises AI Ensure Data Security?

On-premises AI refers to running the model and related components on infrastructure controlled by the organisation.

This approach can reduce certain data transfer risks.

It can be considered particularly in environments where sending sensitive information to external model services is undesirable.

However, using on-premises deployment does not automatically mean a secure system.

#### Remaining risks

Unauthorised user access.

Inadequate network isolation.

Insecure model or software components.

Insufficient logging.

Misconfigured data sources.

Over-privileged AI Agents.

For this reason, in-house model infrastructure must also be protected with both traditional and AI-specific security controls.

### \26. Shadow AI and Supply Chain Security

AI applications often depend on more than one technology provider.

For example:

Model provider.

Cloud infrastructure.

Embedding service.

Vector Database.

SaaS integration.

Third-party plug-ins.

Each of these components must be assessed from a data security perspective.

#### Supplier assessment

The service provider's security controls should be examined.

Data processing agreements should be assessed.

Sub-processors should be identified.

Access permissions should be restricted.

Security incident notification processes should be examined.

Data deletion processes should be defined for when the service is terminated.

This approach shows that Shadow AI risks do not stem from employee usage alone.

AI services purchased by the organisation also require proper supplier assessment.

### \27. Shadow AI and ISO/IEC 42001

ISO/IEC 42001 is the international standard that defines requirements for AI management systems.

It supports organisations in addressing AI usage through an approach of governance, accountability, risk and continual improvement.

Shadow AI management is one of the topics that can be assessed within this scope.

For example, an organisation can:

Build an AI usage inventory.

Define roles and responsibilities.

Carry out risk assessments.

Establish AI policies.

Monitor controls.

Define improvement processes.

However, holding ISO/IEC 42001 certification does not mean that all AI applications in use are technically secure.

The management system approach and technical security verification are complementary processes.

### \28. Shadow AI and ISO/IEC 27001

ISO/IEC 27001 defines the requirements for an information security management system.

Shadow AI risks are related to areas such as the protection of information assets, access control, supplier relationships and data security.

For this reason, Shadow AI management can be integrated into the existing ISMS (Information Security Management System).

For example:

Information asset inventory.

Risk assessment.

Data classification.

Supplier security.

Access control.

Incident management.

Awareness training.

This approach ensures that AI security is not treated separately from the organisation's existing information security processes.

### \29. What Is a Shadow AI Security Assessment?

A Shadow AI Security Assessment is an exercise carried out to identify an organisation's uncontrolled or insufficiently assessed AI usage and to analyse the related security risks.

This assessment can cover both technical and administrative components.

#### Assessment stages

**\1. Discovery:** The AI services in use and their integrations are identified.

**\2. Data analysis:** The types of data being processed are assessed.

**\3. Risk classification:** Use cases are classified according to their potential impact.

**\4. Control assessment:** Existing DLP, CASB, access and data protection mechanisms are examined.

**\5. Policy analysis:** The organisation's AI usage rules are assessed.

**\6. Remediation plan:** Technical and administrative actions are determined.

This exercise can help the organisation bring its AI usage under greater control without blocking it.

### \30. Example Scenario: Shadow AI in a Software Development Team

Imagine that developers at a software company are using different AI code assistants.

Some employees use corporate accounts.

Others work with personal accounts.

Some tools can access repository content.

However, the organisation has no central AI usage policy.

#### Risk 1: Source code transfer

Confidential source code may be sent to external services.

#### Risk 2: Credential leakage

Access credentials in configuration files may be shared.

#### Risk 3: Supplier uncertainty

The data processing terms of the different services may not have been assessed.

#### Risk 4: Unauthorised integration

A code assistant may have broader repository access than necessary.

#### Risk 5: Lack of auditability

It may not be known which tools are being used.

#### Secure approach

Approved code assistants should be designated.

Repository access should be restricted.

Secret scanning should be applied.

Corporate data processing terms should be assessed.

Usage policies should be established.

Where necessary, a central security gateway should be used.

This example shows that Shadow AI security is not limited to chat applications in a web browser.

### \31. Example Scenario: Uncontrolled AI Use in Customer Service

A customer service team uses AI to respond to incoming support requests more quickly.

Employees copy customer messages and send them to an external service.

However, the messages may contain customer identity details, telephone numbers and order details.

#### Potential risks

Transfer of personal data.

Unclear data processing conditions.

Sharing more data than necessary.

Generation of incorrect responses.

Lack of auditability.

#### Secure solution approach

An approved AI integration can be built with the customer support system.

Unnecessary personal information can be masked.

User access can be restricted.

Responses can be passed through appropriate checks.

Data processing conditions can be assessed.

This approach can reduce data security risks while continuing to meet employees' productivity needs.

### \32. Shadow AI Incident Response Process

When data sharing caused by Shadow AI is suspected, the organisation should have a defined incident response process.

For example, an employee may have accidentally uploaded customer data to an external AI service.

#### Initial assessment

What data was shared?

Which service was used?

When was the data transferred?

Which account was used?

Is the data sensitive?

#### Impact analysis

Does it contain personal data?

Does it contain credentials?

Is there information that qualifies as a trade secret?

What are the service's data retention conditions?

#### Response

Where appropriate, a data deletion request can be considered.

If credentials were shared, access credentials must be renewed.

Relevant system logs should be reviewed.

Legal notification obligations should be assessed.

Controls to prevent recurrence should be defined.

#### An important point

Not every instance of Shadow AI usage is a data breach.

However, suspected unauthorised data transfer should be investigated on a risk basis.

If a personal data breach has occurred, the notification requirements under the relevant legislation must be assessed separately.

### \33. A Roadmap for Corporate Shadow AI Management

Organisations that want to manage Shadow AI risks can adopt a phased approach.

#### Phase 1: Visibility

The AI services in use are identified.

Department-level use cases are mapped.

Data flows are assessed.

#### Phase 2: Risk analysis

Sensitive data types are classified.

Supplier risks are assessed.

Regulatory obligations are reviewed.

#### Phase 3: Policy

Approved services are designated.

Data sharing rules are established.

Approval processes are defined for critical operations.

#### Phase 4: Technical controls

AI DLP is evaluated.

Data masking is applied.

Access control is strengthened.

An AI Gateway is used where necessary.

#### Phase 5: Training

Secure AI usage is explained to employees.

Department-specific examples are provided.

Incident reporting processes are explained.

#### Phase 6: Continuous monitoring

New AI services are tracked.

Risk assessments are updated.

Security controls are tested.

This approach turns Shadow AI management from a one-off project into a continuous governance process.

### \34. The SECURESYS Approach to Shadow AI and Corporate Data Security

At SECURESYS, we believe that the Shadow AI problem cannot be solved simply by blocking access to AI services.

This is because organisations' need to benefit from AI technologies persists.

What matters is making this usage visible, controlled and auditable.

In this context, the following areas can be assessed together according to corporate needs:

#### Shadow AI Assessment

Assessing the AI services the organisation uses and its uncontrolled usage scenarios.

#### AI Data Security

Classifying and protecting the data transferred to AI applications.

#### AI DLP Architecture

Establishing the policy and technical architecture for controlling the transfer of sensitive data.

#### Data Masking

Protecting personal and sensitive information before it is transferred to model services.

#### AI Gateway Security

Designing centralised model access and usage policies.

#### AI Agent Security

Assessing the data and operational permissions of AI agents.

#### KVKK and GDPR Technical Security Assessment

Examining personal data processing activities in terms of technical security controls.

#### AI Security Testing

Testing AI applications against data leakage and abuse risks.

SECURESYS's Bastiyon AI Gateway approach can also be assessed in terms of enforcing centralised security policies, masking sensitive data, auditing usage and managing certain agent controls.

However, it should not be forgotten that secure AI usage does not depend on a single product alone.

Corporate policy, access control, data classification, supplier management and employee awareness must be addressed together.

**The aim is not to stop the use of AI, but to benefit from AI without losing control of corporate data.**

### \35. Shadow AI Security Checklist

#### Visibility

- Have the AI services in use been added to the inventory?
- Have department-level use cases been identified?
- Has the use of personal accounts for corporate purposes been assessed?
- Have unauthorised integrations been reviewed?

#### Data security

- Have sensitive data types been classified?
- Has a source code sharing policy been established?
- Are there controls to prevent the sharing of credentials?
- Has data masking been assessed?

#### Regulatory compliance

- Have KVKK obligations been assessed?
- Has the applicability of the GDPR been examined?
- Has the transfer of data abroad been analysed?
- Have data processing agreements been assessed?

#### Technical controls

- Are AI DLP policies in place?
- Have approved services been designated?
- Are access controls being enforced?
- Has audit logging been assessed?
- Has the need for an AI Gateway been analysed?

#### Operational security

- Is awareness training being provided to employees?
- Is there a Shadow AI incident reporting process?
- Are new services assessed regularly?
- Are risk assessments kept up to date?

This checklist can be extended according to the organisation's data sensitivity, sector and AI usage model.

### Frequently Asked Questions

#### What is Shadow AI?

Shadow AI refers to AI applications and processes that are used outside the organisation's approval, visibility or security controls.

#### Why is Shadow AI dangerous?

It can create risks such as uncontrolled transfer of sensitive data, unauthorised integrations, supplier uncertainty and lack of auditability.

#### What is the difference between Shadow AI and Shadow IT?

Shadow IT generally refers to uncontrolled technology use. Shadow AI is the dimension of this problem that is specific to AI applications.

#### Is it safe to upload company data to AI?

Security depends on the sensitivity of the data, the service used, the contractual terms and the controls applied.

#### Is it risky to send source code to AI?

Yes. Source code may contain intellectual property, architectural information or access credentials. Sharing must therefore be controlled.

#### Do AI services store the data sent to them?

Retention conditions vary depending on the provider, the type of product and the contract settings. Each service must be assessed separately.

#### Is Shadow AI a KVKK violation?

Not every instance of Shadow AI usage is automatically a KVKK violation. However, if personal data is being processed, the relevant legal and technical obligations must be assessed.

#### Does Shadow AI pose a risk under the GDPR?

Yes. Processing or transferring personal data that falls under the GDPR without appropriate legal and technical controls can create risk.

#### What is AI DLP?

AI DLP is a data loss prevention approach aimed at detecting and controlling the transfer of sensitive data in AI usage.

#### What is an AI Gateway?

An AI Gateway is a layer that can be used to manage communication between AI applications and model services under centralised security and usage policies.

#### Does data masking ensure AI security?

Data masking can reduce certain risks, but on its own it does not meet all AI security needs.

#### Is on-premises AI completely secure?

No. Using an in-house model can reduce some data transfer risks, but access, infrastructure and application security controls are still required.

#### How is Shadow AI detected?

Web access visibility, CASB, SSE/SASE, endpoint controls, SaaS inventory and corporate assessment processes can be used together.

#### Can Shadow AI be blocked completely?

It cannot be guaranteed that every route of use can be blocked with a single control. Risk can be reduced through layered technical and administrative controls.

#### Does ISO/IEC 42001 help with Shadow AI management?

Yes. Through the AI management system approach, it can support the creation of a usage inventory, risk assessment, responsibilities and control processes.

### Conclusion: An Organisation That Cannot Manage AI Usage Will Struggle to Manage Its Data Flows

AI applications are becoming an increasingly important part of corporate business processes.

Employees prepare reports faster.

Software developers get support with code generation.

Sales teams prepare proposals.

Human resources teams analyse documents.

Customer support teams try to shorten response times.

Yet in all of these use cases, there is one common security question:

#### With which AI services, for what purposes and under which controls is corporate data being shared?

This lack of visibility is at the heart of the Shadow AI problem.

If an organisation does not know which services are being used, it may struggle to assess data transfers.

If it does not know what data is being sent, it may be unable to protect sensitive information.

If it does not know which integrations exist, it may be unable to manage access permissions.

For this reason, Shadow AI management is not merely an access-blocking policy.

It is an important part of corporate AI governance.

A secure approach means:

Making AI usage visible.

Classifying sensitive data.

Designating approved services.

Controlling data transfers.

Applying masking where necessary.

Assessing supplier and regulatory obligations.

Offering employees secure alternatives.

And continuously monitoring the controls.

Benefiting from AI and protecting corporate data are not opposing goals.

With the right security architecture, they can be managed together.

**The core goal of Shadow AI security is not to ban AI usage, but to make secure use possible while preserving the organisation's control over its data.**