3,136 subscribersSubscribed

The AI Act and Enterprise AI Adoption: What It Really Means Beyond the Marketing

Antonio Ieranò

Information & Cybersecurity Strategist | Digital Sovereignty • AI Governance • Complex Systems | Author, Researcher & Occasional Philosopher | Views stubbornly my own. 🧠

October 8, 2026

:The AI Act comes at a time when companies are no longer treating artificial intelligence as an experimental technology. AI is now being embedded into the operating fabric of the enterprise: SOC platforms, DLP tools, data protection systems, cloud environments, ticketing systems, productivity suites, internal search engines, data management workflows, HR systems, procurement processes, CRMs, identity governance tools and software development platforms.

This changes the perspective. The issue is no longer simply “can we use ChatGPT?” or “does the vendor claim to have an AI copilot?”. The real question is: what does it mean for a company to incorporate AI components into its own systems from a regulatory, organisational, contractual, technical and accountability standpoint?

The AI Act is part of the answer. It is not the whole answer. Alongside the AI Act, companies must consider the GDPR, international data transfers, Schrems II, SCCs, TIAs, DPAs, supplementary measures, cloud sovereignty, contractual safeguards and technical security. Above all, this requires the involvement of corporate functions that can no longer operate in silos: the CISO, DPO, CIO, legal, procurement, risk management, internal audit, data office, HR and senior leadership.

1. The AI Act does not regulate AI marketing. It regulates roles, uses and risks

The first mistake is to read the AI Act as a generic law on “AI products”. The AI Act is less concerned with how a vendor describes its solution and more concerned with what the system actually does, who places it on the market, who uses it, what data it processes, how autonomous it is and what impact it may have.

This matters because almost every vendor now claims to offer AI capabilities: AI assistants, AI agents, AI SOC analysts, AI copilots, AI-driven DLP, AI-powered data discovery, autonomous response, AI governance, GenAI security, AI threat intelligence, AI for identity and AI for cloud posture management. But the commercial label does not determine the regulatory position.

For the AI Act, the key questions are:

Is the system placed on the EU market?
Is it used in the European Union?
Is the output produced by the system used in the EU, even if the provider is outside the EU?
Is the company acting as provider, deployer, importer, distributor or internal user?
Does the system fall into a prohibited, high-risk, transparency-related or low-risk category?
Does it use or incorporate a general-purpose model, such as an LLM?
Does it generate synthetic content, recommendations, classifications, decisions or automated actions?
Does it affect individuals, access rights, employment, credit, education, essential services, security or fundamental rights?

The scope of the AI Act may also include operators established in third countries where the output of the AI system is used in the Union. This is a crucial point for US vendors and global cloud architectures.

In other words: the fact that a system runs in the United States does not automatically place it outside the European perimeter.

2. The AI Act is not a data residency law, but it exposes operational risk

Another common misunderstanding is to assume that the AI Act, by itself, requires all AI-related data to remain in Europe. It does not. The AI Act is not a data localisation regulation. Its structure is risk-based: some uses are prohibited, some are high-risk, some trigger transparency obligations, and others remain largely unrestricted, although not necessarily risk-free.

However, the AI Act has a very concrete effect: it forces companies to understand which AI systems they are using, for what purpose, with what data, with what degree of autonomy and with what controls.

That is already a major shift. Many organisations today do not have a reliable inventory of AI capabilities embedded in their tools. AI may be present in the EDR, the SIEM platform, the DLP engine, the CASB, the data classification tool, the customer support system, the collaboration suite, the HR platform or the development environment. Sometimes it is visible as an explicit feature. Sometimes it is embedded, activated by the vendor or introduced through an update.

The AI Act pushes companies to move from generic vendor trust to verifiable governance.

3. Security, DLP and data protection: why AI is becoming unavoidable

Cybersecurity is one of the areas where avoiding AI is becoming increasingly unrealistic. The volume of events, logs, alerts, anomalies, identities, endpoints, cloud flows, SaaS data and threats makes a purely manual approach less and less sustainable.

AI is used to:

correlate security events;
classify alerts;
prioritise incidents;
generate detection queries and rules;
summarise evidence;
identify anomalous patterns;
detect data exfiltration;
classify sensitive data;
suggest remediation actions;
automate playbooks;
support threat hunting;
analyse suspicious emails;
enrich incidents with threat intelligence;
interpret user or machine behaviour;
manage cloud posture and identity risk.

The same applies to DLP, data protection and data management. Companies need tools capable of finding sensitive data, understanding where it resides, classifying it, deduplicating it, applying retention rules, identifying improper exposure, recognising personal data in unstructured environments, protecting datasets and preventing leakage into GenAI tools.

The question, therefore, is not whether to use AI. The question is how to incorporate it under proper control.

4. The delicate boundary: from technical assistance to decisions affecting people

In security, many AI use cases appear purely technical and therefore low-risk. That is not always the case.

A copilot that helps an analyst write a SIEM query has a different risk profile from a system that assigns a risk score to an employee. A tool that classifies malware is different from one that identifies a user as a potential insider threat. A system that suggests remediation is different from an agent that automatically blocks accounts, revokes privileges, isolates devices or initiates internal procedures.

The critical point is when AI produces effects, even indirectly, on natural persons. Examples include:

behavioural scoring of employees;
classification of “risky” users;
monitoring of internal communications;
analysis of productivity or workplace conduct;
automatic blocking of corporate accounts;
recommendations that influence disciplinary proceedings;
classification of customers or users for fraud risk;
correlation of identity, device, location and behaviour;
use of biometric or particularly sensitive data;
profiling through metadata.

Companies should not be reassured simply because a tool is labelled as “cybersecurity”. A system may be designed to protect the organisation and still have significant effects on rights, freedoms, employment, reputation and access to services.

5. The AI Act and GPAI: what it means to use LLMs and general-purpose models

Many enterprise solutions now incorporate LLMs or general-purpose models. Sometimes the vendor uses its own model. Sometimes it integrates models from hyperscalers or third-party providers. Sometimes the customer can choose between several models. Sometimes prompts, logs, documents, tickets or metadata are sent to an external service.

The AI Act also regulates general-purpose AI models. For the enterprise customer, this does not mean that every use of an LLM automatically makes the company a GPAI provider. But it does mean that procurement must ask:

Which model is being used?
Who is the model provider?
Where is the model executed?
What company data is sent to the model?
Is customer data used for training or fine-tuning?
Is there an opt-out from training?
What logs are retained?
For how long?
Who can access them?
Are subprocessors involved?
In which countries?
Is model output used in critical business processes?
Can the company explain and reconstruct how the system was used?

These questions are particularly important for AI agents and copilots. An “agent” is not just a chatbot. It may read data, call APIs, query systems, open tickets, modify configurations, block users, generate code, update rules or trigger workflows. The autonomy of the agent therefore becomes a central part of the assessment.

6. Personal data, transformed data, embeddings and metadata

One of the most underestimated issues concerns “transformed” data. Many AI architectures do not necessarily send the original document to the model, but process embeddings, vectors, metadata, hashes, semantic indexes, classifications, tokens, chunks, summaries or derived representations.

The risk is to assume that, because the data has been transformed, it is no longer personal data. That is not always true.

The GDPR distinguishes between anonymisation and pseudonymisation. Pseudonymisation reduces the linkability of data to an individual, but does not automatically take it outside the GDPR. Only truly anonymised data, meaning data that is no longer attributable to an identified or identifiable person, falls outside the GDPR.

This has direct consequences for AI, security and data management.

An embedding generated from a document containing personal data may retain semantic information related to the original content. Metadata can be highly identifying: user ID, device ID, IP address, tenant ID, location, corporate role, timestamp or behavioural pattern. A summary may contain personal information even if the original document is not stored. A vector index may enable inference or retrieval of sensitive content.

So the right question is not: “Have we transformed the data?”. The right question is: can the transformed data still reasonably be linked to a person, directly or indirectly, using means reasonably available?

If the answer is yes, the company should treat it as personal data.

7. GDPR: the real driver of the data assessment

When AI processes personal data, the GDPR remains central. The AI Act does not replace it.

For a company incorporating AI into its systems, the GDPR requires consideration of:

lawful basis;
specific purposes;
data minimisation;
storage limitation;
transparency towards data subjects;
data subject rights;
security of processing;
privacy roles: controller, processor, joint controller;
subprocessors;
DPIA where processing is likely to result in high risk;
transfers outside the EEA;
technical and organisational measures.

The DPIA often becomes essential where AI processes personal data extensively, innovatively, systematically or in a way that may significantly affect individuals.

For many companies, the challenge is not merely to produce a formal DPIA, but to connect it to the AI Act assessment, security review, vendor risk assessment and procurement process. A privacy questionnaire separated from a security questionnaire and an AI questionnaire often produces an incomplete picture.

8. Schrems II, SCCs, TIAs and international transfers

Many AI components reside in the United States or are managed by global vendors. Even where the data centre is in Europe, there may still be support access, telemetry, logging, subprocessors, model hosting, content moderation, abuse monitoring or technical escalation outside the European Economic Area.

This brings international transfers into scope.

After Schrems II, Standard Contractual Clauses remain an important tool, but they are not a magic wand. In practice, when a company uses a non-EU AI vendor or a service that involves non-EEA access to personal data, it must ask:

What transfer mechanism is used?
Is there an adequacy decision?
Are SCCs in place?
Does the vendor participate in a recognised framework, where applicable?
Is a Transfer Impact Assessment required?
What risks arise from the laws of the third country?
What supplementary measures are applied?
Is the data encrypted?
Who controls the keys?
Can the vendor access data in the clear?
Are subprocessors mapped?
Are support accesses limited, logged and approved?
Is data used for training or service improvement?
What logging and retention rules apply?

In the AI context this becomes even more important because data may appear in several forms: prompts, outputs, logs, embeddings, telemetry, feedback, error examples, fine-tuning datasets, caches, memory and agent traces.

9. DPAs and contracts: what to ask vendors in practice

The Data Processing Agreement should not be a generic annex signed at the end of the procurement cycle. In AI projects, it must become an operational instrument.

A proper vendor assessment should clarify at least:

the vendor’s privacy role: processor, independent controller or joint controller;
processing purposes;
categories of data processed;
categories of data subjects;
data location;
access from third countries;
subprocessors;
training, fine-tuning and service improvement;
use of customer data for telemetry or product analytics;
retention of prompts, outputs and logs;
deletion and return of data;
incident management;
audit rights;
tenant segregation;
encryption in transit and at rest;
key management;
administrative logging;
support access;
vulnerability management;
model monitoring;
safeguards against prompt injection, data leakage and misuse;
responsibility for incorrect outputs or harmful automated actions.

For AI agents, specific additional questions are needed:

What actions can the agent perform?
With which privileges?
Can it modify configurations?
Can it block accounts?
Can it send communications?
Can it access sensitive data?
Can it call external tools?
Is human approval required?
Are there autonomy limits?
Is there an audit trail of actions?
Can the decision chain be reconstructed?
Can unnecessary agentic functions be disabled?

Often, the most important contractual clause is not the one stating that the vendor is “compliant”, but the one that prevents unauthorised secondary use, limits retention and training, governs subprocessors, requires transparency on access and provides audit rights or equivalent evidence.

10. Cloud sovereignty: not only where data is stored, but who can control it

Cloud sovereignty is not the same as data centre region. Saying “the data is in Europe” is useful, but not sufficient.

Companies must distinguish between:

data residency;
place of processing;
place of administrative access;
nationality and corporate control of the provider;
access by non-EU personnel;
cryptographic key management;
subprocessors;
telemetry and logs;
technical support;
resilience and business continuity;
exit capability;
portability;
dependencies on proprietary models or services.

In the AI context, sovereignty is more complex because the main dataset is not the only asset requiring protection. Embeddings, prompts, outputs, feedback, policies, classifications, knowledge bases, agent traces and generated rules may also be sensitive.

For the CISO, this means that sovereignty assessment must not stop at infrastructure. It must include the AI supply chain.

11. What this means in practice for the company

For an enterprise, the AI Act should translate into a practical programme, not a standalone document.

The first step is inventory. The company must know where AI is already present. This includes formally purchased tools, features activated in existing SaaS platforms, cloud components, APIs used by development teams, individual copilots, browser extensions, security tools, data tools, automation features and agents.

The second step is classification. For each use case, the company must understand:

what the system does;
what output it produces;
whether the output is used in the EU;
what data it processes;
whether it processes personal data;
whether it processes special categories of data;
whether it affects individuals;
whether it falls into high-risk areas;
whether transparency obligations apply;
whether it incorporates GPAI;
whether it generates synthetic content;
whether it acts autonomously.

The third step is governance. Every relevant AI system should have an owner, an approval process, controls, evidence, documentation and monitoring.

The fourth step is procurement. AI vendors must be assessed through specific questions, not generic questionnaires recycled from cloud risk assessments.

The fifth step is operational control. The company must be able to limit data, privileges, actions, logging, retention and access.

The sixth step is training. It is not enough to train “users on ChatGPT”. Procurement, IT, security, legal, privacy, data owners, developers, HR and management must be trained to recognise relevant AI use cases.

12. The role of the CISO

The CISO is central, but cannot be left alone.

From the CISO’s perspective, AI introduces at least four layers of risk:

AI as a defensive tool SOC copilots, detection, DLP, data classification and response automation.
AI as an attack surface Prompt injection, data leakage, model abuse, agent hijacking, model supply chain and plugin/tool misuse.
AI as a governance risk Shadow AI, unauthorised use of external tools, lack of logging and unverified outputs.
AI as a critical dependency Vendor lock-in, model unavailability, policy changes, uncontrolled model updates and regressions.

The CISO should therefore require concrete controls:

inventory of AI solutions;
classification of data sent to AI systems;
access control;
privilege segregation;
logging and audit trails;
red teaming or testing for prompt injection and data leakage;
connector control;
human approval for high-impact actions;
monitoring of agent actions;
AI-specific incident response;
security requirements in vendor contracts;
integration with risk management and the DPO.

13. The role of the DPO

The DPO must be involved early, not at the end.

Many AI projects begin as technology initiatives, but quickly become personal data processing activities. This is particularly true when AI is integrated into productivity, security, HR, customer care, analytics, data management or identity tools.

The DPO should help the company assess:

whether personal data is involved;
whether special categories of data are involved;
whether the processing is compatible with the original purpose;
whether a DPIA is required;
whether there are transfers outside the EEA;
whether embeddings and metadata remain personal data;
whether the privacy notice is adequate;
whether data subject rights can be exercised;
whether the vendor acts as processor or controller;
whether the DPA is adequate;
whether subprocessors are acceptable;
whether automated decision-making or profiling is involved.

For security tools, the DPO must work with the CISO to avoid two opposite mistakes: blocking everything out of abstract caution, or accepting everything because “it is cybersecurity”. Organisational protection and the protection of individual rights must be designed together.

14. The role of the CIO, CTO and IT teams

The CIO and CTO must translate governance into architecture.

The most important decisions are not only legal, but technical:

which models are authorised;
which APIs may be used;
where data and logs reside;
which environments may send data to external models;
which development tools may use AI;
which data may enter prompts;
how secrets and credentials are handled;
how plugins, connectors and agents are controlled;
how prompts, policies and configurations are versioned;
how a model update is tested;
how an AI feature can be disabled if risks emerge.

Without governed architecture, AI rapidly becomes a constellation of local shortcuts.

15. The role of procurement and legal

Procurement and legal must evolve. Buying an AI-enabled solution cannot be treated like an ordinary SaaS subscription.

The purchasing process must distinguish between:

AI declared by the vendor;
hidden or embedded AI;
optional AI that can be activated;
AI used only for the vendor’s internal support;
AI used on customer data;
AI used for training or improvement;
agentic AI with operational actions;
AI whose output is used in business decisions.

Procurement must ask for evidence, not merely declarations. Legal must translate that evidence into contractual obligations: use limitations, audit rights, subprocessors, data transfers, retention, incident notification, liability, exit, deletion, data rights and restrictions on training.

16. The role of the board and senior leadership

The AI Act makes clear that AI is not merely a technical issue. It is a corporate governance issue.

Senior leadership should ask:

Which critical processes already depend on AI?
Which decisions are influenced by AI?
What level of risk is acceptable?
Who approves AI use cases?
Who can stop an AI system?
What metrics are monitored?
What evidence is available in the event of an audit or incident?
Which AI suppliers have become critical?
Which capabilities are missing?
What degree of agent autonomy is acceptable?

Responsibility cannot remain informally distributed between IT, security and business units. Explicit governance is required.

17. A minimum operating model

A company that wants to address the AI Act and AI governance seriously should build at least the following elements:

AI inventory A list of AI systems used or embedded in corporate systems, including SaaS vendors and security tools.

AI use case register A register of use cases, including purpose, owner, data processed, outputs, users, vendor and level of autonomy.

Risk classification Classification under the AI Act, GDPR, security, business criticality and impact on individuals.

Vendor AI assessment A specific questionnaire for AI vendors, covering models, data, training, retention, subprocessors, transfers, security and agentic capabilities.

Privacy assessment and DPIA Integrated privacy assessment, with a DPIA where required.

Transfer assessment Assessment of non-EEA transfers, SCCs, TIAs, supplementary measures, remote access and subprocessors.

Security architecture review Technical analysis of access, privileges, logging, encryption, key management, connectors, APIs and agents.

Human oversight model Definition of when a human must approve, verify or be able to stop the system.

AI-specific incident response Procedures for AI-related data leakage, harmful outputs, erroneous agent actions, compromised connectors or model abuse.

Board reporting Periodic reporting on AI exposure, critical vendors, risks, incidents, remediation and decisions required.

18. The final question: not “AI yes or no”, but “AI under what controls?”

For many companies, especially in security, DLP, data protection and data management, avoiding AI is not realistic. Operational complexity is too high, and vendors are embedding AI ever more deeply into their platforms.

That is precisely why the discussion must move beyond marketing.

The AI Act does not tell companies to stop. In essence, it says that AI must be understood, classified, documented and governed. The GDPR reminds us that personal data remains protected even when it is transformed, pseudonymised or incorporated into complex flows. Schrems II, SCCs, TIAs and supplementary measures remind us that global services require a concrete assessment of transfers and access. Technical security reminds us that an AI agent with operational privileges is also a new attack surface.

The point is not to chase every vendor claim. The point is to build a stable enterprise capability: to know where AI is used, with what data, by whom, for what purpose, within what limits, under whose responsibility and with what evidence.

A company that treats the AI Act only as compliance will arrive late. A company that uses it as an opportunity to bring order to AI, data, security, cloud and procurement will gain a practical advantage: it will be able to adopt AI faster, with less risk and more control.

Final Note: A Practical Checklist for Assessing AI-Enabled Technology

When a vendor proposes a technology that incorporates artificial intelligence, the company should not stop at the commercial description of the solution. The question is not whether the product “uses AI”, but how it uses AI, with what data, with what effects, with what level of autonomy and under whose responsibility.

The following checklist can be used during procurement, risk assessment, legal review, security review and privacy assessment.

1. Identification of the AI system

Does the product actually incorporate an AI system under the AI Act?
Is the AI functionality core, optional, embedded or activatable later?
Does the system use a proprietary model, a third-party model or a general-purpose model?
Is the vendor the provider of the AI system, an integrator, a reseller or a deployer?
Does the customer become a deployer, provider or materially modify the system?
Will the output of the AI system be used in the European Union, even if the vendor is established outside the EU?

Functions involved: legal, compliance, CIO/CTO, procurement, business owner, risk management.

Reference: AI Act, Article 2 on scope; Article 3 on definitions.

2. AI Act risk classification

Does the use case fall within prohibited AI practices?
Could the system be classified as high-risk?
Does the system affect individuals, employment, access to services, credit, education, health, safety, law enforcement or critical infrastructure?
Does the system generate synthetic content, recommendations, classifications, scoring or decisions?
Do transparency obligations towards users or data subjects apply?
Is specific logging, technical documentation, human oversight or user instruction required?

Functions involved: legal, compliance, DPO, risk management, business owner, HR where employees or candidates are affected, CISO where the system has cyber relevance or privileged access.

References: AI Act, Article 5 on prohibited practices; Article 6 and Annex III on high-risk systems; Article 50 on transparency obligations.

3. Use of LLMs and general-purpose models

Which model is used?
Who is the model provider?
Is the model general-purpose or specialised?
Is company data used for training, fine-tuning, evaluation or service improvement?
Can the use of customer data for training be contractually excluded?
Where are prompts, outputs, logs, embeddings and feedback stored?
Does the vendor provide adequate documentation on the model, its limits and risks?
Can the model produce outputs used in critical operational or decision-making processes?

Functions involved: CIO/CTO, CISO, data office, legal, procurement, DPO, business owner, enterprise architecture.

References: AI Act provisions on GPAI models, particularly Articles 53 and 55; European Commission guidance on general-purpose AI models.

4. Data processed

What data is sent to the AI system?
Is personal data involved?
Are special categories of personal data involved?
Is confidential business information, trade secrets, credentials, security logs or regulated data involved?
Does the system process original data, transformed data, metadata, embeddings or vectors?
Is transformed data truly anonymised or only pseudonymised?
Is there a clear retention policy for inputs, outputs, logs and derived data?
Can the vendor access data in the clear?

Functions involved: DPO, data office, CISO, CIO/CTO, legal, business data owner, compliance.

References: GDPR, Article 4 on personal data and pseudonymisation; Article 5 on processing principles; Article 25 on data protection by design and by default; Article 32 on security of processing.

5. Privacy and DPIA

What is the lawful basis for the processing?
Are the purposes specific, explicit and legitimate?
Is the processing compatible with existing privacy notices?
Do data subjects need to be informed about the use of AI?
Does the system involve profiling or automated decision-making?
Is a DPIA required?
Has the DPO been involved before purchase or activation?
Can data subject rights be exercised in relation to AI data, logs and outputs?

Functions involved: DPO, legal, compliance, business owner, HR where employees or candidates are concerned, customer operations where customers are concerned, CISO for security measures.

References: GDPR, Article 6 on lawful basis; Articles 12-15 on transparency and access; Article 22 on automated decision-making; Article 35 on DPIA.

6. International transfers

Is data transferred outside the European Economic Area?
Is there remote access from third countries?
Are subprocessors located outside the EU?
What transfer mechanism is used?
Is an adequacy decision applicable?
Have Standard Contractual Clauses been signed?
Has a Transfer Impact Assessment been carried out?
Are technical, organisational and contractual supplementary measures in place?
Who controls the encryption keys?
Could the vendor be subject to access requests from non-EU authorities?

Functions involved: DPO, legal, procurement, CISO, CIO/CTO, vendor management, risk management.

References: GDPR, Articles 44-49 on international transfers; Schrems II; European Commission SCCs; EDPB recommendations on supplementary measures.

7. Technical security and agentic AI

Can the AI system act autonomously or only make suggestions?
What actions can it perform?
With which privileges?
Can it modify configurations, block accounts, delete data, send communications or open tickets?
Is there a human approval mechanism?
Are the agent’s actions logged and reconstructable?
Is the system protected against prompt injection, data leakage, connector abuse and privilege escalation?
Can tools, APIs, connectors and accessible data sources be restricted?
Are there security tests specifically covering AI capabilities?

Functions involved: CISO, security architecture, SOC, IAM, CIO/CTO, enterprise architecture, risk management, DPO where personal data is processed.

References: AI Act requirements on robustness, accuracy and cybersecurity for high-risk systems; GDPR, Article 32; NIS2 where applicable to essential or important entities.

8. Contracts, DPA and liability

Does the DPA accurately describe the AI processing?
Does the vendor act as processor, independent controller or joint controller?
Are subprocessors, locations, purposes, retention and security measures specified?
Is unauthorised use of customer data for training prohibited?
Are there notification obligations for incidents, data breaches and AI malfunctions?
Are audit rights or equivalent evidence provided?
Does the contract address model changes, new AI features and substantial modifications?
Are deletion, return and exit obligations included?
Are responsibilities clear in the event of incorrect outputs or harmful automated actions?

Functions involved: legal, procurement, DPO, CISO, vendor management, risk management, finance where there are insurance or economic liability implications.

References: GDPR, Article 28 on processors; Articles 32-34 on security and data breaches; AI Act obligations for providers and deployers.

9. Internal governance

Who is the business owner of the AI use case?
Have the CISO, DPO, legal, procurement, CIO/CTO, risk management and business owner been involved?
Does the board or senior management have visibility of the most critical AI use cases?
Is there an internal register of AI systems?
Is there an approval process before new AI functions are activated?
Is there a process to suspend or disable a risky AI function?
Are periodic controls in place for performance, security, bias, errors, incidents and vendor changes?
Are users trained on the limits of the system?

Functions involved: senior management, board where relevant, compliance, risk management, internal audit, CISO, DPO, CIO/CTO, legal, procurement, business owner.

References: AI Act governance of AI systems and deployer obligations; GDPR accountability principle, Articles 5(2) and 24.

10. Summary map of internal responsibilities

Board and senior management: define risk appetite, priorities, responsibilities and acceptable levels of AI autonomy.
CISO: assesses technical security, cyber exposure, access, privileges, logging, incident response and AI agent risk.
DPO: assesses personal data, DPIAs, privacy notices, data subject rights, transfers and privacy roles.
Legal: translates risks and obligations into contracts, DPAs, SCCs, liability clauses, audit rights, exit provisions and use restrictions.
Compliance and risk management: classify risk, maintain the control framework and ensure alignment with applicable regulation.
CIO/CTO: assess architecture, integration, operating model, technical controls, scalability and technology dependencies.
Data office: assesses data quality, classification, lineage, minimisation, data governance and use of derived data.
Procurement and vendor management: verify vendors, subprocessors, documentation, evidence, contractual terms and supply risk.
HR: must be involved where AI concerns employees, candidates, performance, monitoring or work organisation.
Internal audit: verifies that policies, controls and registers are actually implemented, not merely declared.
Business owner: remains responsible for the purpose of use and operational impact of the system within the business process.

11. The final question to ask the vendor

Before approving an AI technology, the company should ask the vendor for a documented answer to this question:

“Can you describe, in a verifiable and contractually binding way, which AI components you use, what data you process, where you process it, whether you use it for training, what outputs you produce, what automated actions you can perform, which subprocessors you involve, what non-EU transfers occur, what security measures you apply and which AI Act/GDPR obligations you consider applicable?”

The answer to this question directly concerns the CISO, DPO, legal, procurement, CIO/CTO, risk management and business owner. In the most critical cases, it should also reach senior management, because AI adoption is no longer a purely technical choice: it is a governance decision.

If the answer is vague, incomplete or purely commercial, the risk has not been understood. And if the risk has not been understood, it cannot be governed.