Deploying AI in the enterprise without opening a hole: control, governance and measurement

By Kike Gandia · AI & Security · 18 min read

The conversation about AI in Spanish companies has moved on in eighteen months. It is no longer about whether to use it: it is about the fact that it is already in use, almost always before anyone authorized it, and that the department that should be setting limits usually finds out the day someone pastes a customer contract into a public chatbot. That is the real starting point, and it is worth stating plainly because it shapes everything else: you are not deciding whether to adopt AI, you are deciding whether the AI already circulating in your organization goes through a control or not.

20%

of organizations suffered a breach caused by unauthorized AI (IBM Cost of a Data Breach 2025)

$670,000

in average added cost when shadow AI is behind the breach (Against a global average of $4.44M)

95%

of generative AI pilots with no measurable impact on the P&L (MIT NANDA 2025 — preliminary study)

€35M or 7%

maximum AI Act fine for prohibited practices (Article 99, of worldwide turnover)

The top two figures measure the cost of not controlling. The bottom two, the cost of not measuring and of not complying.

It's a false choice: neither ban it nor let it run wild

Both knee-jerk reactions fail, and the failures are well documented. An outright ban does not eliminate use: it makes it invisible. Adoption without controls does not create value on its own either, because the bottleneck was never the model.

Banning it by memo The policy nobody follows

• Use doesn't go away: it moves to personal accounts and personal devices, outside any logging.
• 83% of organizations have no technical control to stop data being uploaded to a public AI: they rely on training, or on nothing.
• When an incident happens there are no traces, because the tool that caused it was never inventoried.
• It penalizes those who ask and rewards those who stay quiet.

Adopting it without controls The pilot that goes nowhere

• 97% of organizations with an AI-related breach lacked access controls for that AI.
• 63% had no written governance policy at all.
• With no defined outcome and no integrated data, the pilot cannot be evaluated: it is neither scaled up nor killed.
• Every team picks its own vendor, and nobody knows what is being trained on your data.

The two columns end up in the same place by opposite routes: nobody knows what is going on.

The third way is boring and it works: adopt with control. Inventory what is already there, classify it by risk, channel it through a single point where logging and data loss prevention are applied, give agents the least privilege they need and measure with metrics that cannot be used to dress each other up. The rest of this article covers how to do that, in what order and how to verify it.

The attack surface AI really opens up

An AI system does not simply inherit a web application's attack surface: it extends it with a class of failure that did not exist before. In a web application, the vulnerability lives in a code path. In a language model, it lives in behavior: in what the model says and what it does when someone talks to it in a certain way. The reference catalog is the OWASP Top 10 for LLM Applications, which is best read as a checklist rather than a curiosity.

LLM01 Prompt injection

Inputs that rewrite the model's instructions. The indirect variant — via a web page, an email or a document the system reads — is the dangerous one for agents.

LLM02 Sensitive information disclosure

Confidential data that comes out in the response. It rose from sixth to second place in the 2025 revision.

LLM03 Supply chain

Downloaded models, dependencies, MCP servers and extensions. Insecure deserialization included.

LLM04 Data and model poisoning

Data tampered with during training, fine-tuning or in the corpus that feeds retrieval.

LLM05 Improper output handling

Executing or rendering what the model returns without validating it. Output is untrusted input.

LLM06 Excessive agency

Permissions and tools the use case does not need. This is what turns a mistake into an incident.

LLM07 System prompt leakage

Internal instructions end up exposed, with business logic and sometimes credentials inside.

LLM08 Vector and embedding weaknesses

Overshared indexes and permissions that are not inherited from the source document.

LLM09 Misinformation

Plausible but false answers that someone acts on without checking, with real operational impact.

LLM10 Unbounded consumption

Cost and denial of service from usage with no quotas or limits.

OWASP Top 10 for LLM Applications. The 2026 edition keeps the structure and draws on thousands of real incidents.

Agents are the fastest-growing part

As long as a model only answers, the potential damage is limited to what it says. Once you give it tools — reading email, writing to the CRM, running code, opening a ticket — the potential damage becomes whatever those tools can do. OWASP already catalogs fifteen threats specific to agentic systems, and in 2025 MITRE ATLAS added fourteen agent-focused techniques. These are the ones that show up first in practice:

• Memory poisoning. A false fact the agent stores today shapes every decision it makes tomorrow.
• Tool misuse. The agent does what it is asked, but with the wrong tool and on the wrong object.
• Privilege compromise. Service credentials shared between agents and reused beyond their purpose.
• Intent breaking. The agent's goal is hijacked midway through a task by external content.
• Rogue agents in multi-agent systems. A compromised agent that contaminates the others through its messages.
• Overwhelming the human in the loop. So many confirmation prompts that the person ends up approving without reading, which is exactly the failure oversight was meant to prevent.

On prompt injection, it pays to be honest

There is no complete fix, and anyone who says otherwise is selling something. OWASP says so explicitly: given the stochastic nature of these models, it is unclear whether foolproof prevention methods exist. Any serious architecture assumes an injection will eventually get through and is designed so that, when it does, the damage is bounded by permissions rather than by luck.

What do exist are design patterns that shrink the surface considerably. The two most cited are complementary, and neither eliminates the problem:

Dual-LLM Simon Willison, 2023

• A privileged model that never sees untrusted data.
• A second, quarantined model that does process it, but has no access to tools.
• Protects control flow; does not protect data flow.
• Cheap to implement on top of an existing architecture.

CaMeL Google DeepMind, 2025

• Refines the former with control-flow integrity and explicit capabilities.
• Information flow control through a restricted interpreter.
• Defended against 67% of attacks on the AgentDojo benchmark.
• Costs performance and adds implementation complexity.

Both mitigate and neither eliminates. That is why least privilege is not optional: it decides how much an injection that does succeed will hurt.

Shadow AI: the real cost of banning it

In 2025, IBM's annual report on the cost of data breaches put a number on something that until then had been a hunch. Shadow AI made it into the top three factors driving up the cost of an incident, ahead of staffing shortages, and it does so for a specific reason: it exposes data that is normally better protected. Breaches involving shadow AI exposed customer personal data in 65% of cases, compared with an average of 53%, as well as intellectual property, the most expensive type of record of all.

Anatomy of the failure, according to IBM and Ponemon across 600 organizations. This is not an awareness problem: it is a problem of controls that do not exist.

The practical takeaway is that training alone does not move the needle. Only 17% of organizations have a technical control that prevents confidential data from being uploaded to a public AI tool. Until that control exists, the policy is a statement of intent — and the breach is a matter of time.

The real AI Act timeline (and the most expensive misreading)

In May 2026, the agreement known as the Digital Omnibus postponed part of Regulation (EU) 2024/1689. Much of the market read it as a general pause, and it is not. What moved was the high-risk block. The prohibitions, mandatory AI literacy, the rules for general-purpose models and the penalty regime have all been in force since 2025.

AI Act timeline: entry into force on August 1, 2024; Article 5 prohibitions and Article 4 literacy obligations from February 2, 2025; general-purpose model obligations and the penalty regime from August 2, 2025; Article 50 transparency from August 2, 2026; Annex III high-risk obligations postponed to December 2, 2027 and Annex I to August 2, 2028.

The other common misconception is that using AI automatically means falling into high risk. The classification is determined not by the technology but by the purpose: the same model is minimal risk when drafting an internal email and high risk when screening candidates in a hiring process.

AI Act risk levels: prohibited (social scoring, subliminal manipulation, emotion recognition in the workplace), punishable by fines of €35 million or 7% of worldwide turnover; high risk (recruitment, credit scoring, biometrics, critical infrastructure), requiring risk management, technical documentation, human oversight and a fundamental rights impact assessment, with fines of up to €15 million or 3%; limited risk (chatbots and generated content), subject to transparency obligations; minimal risk (writing assistants, internal summaries, coding copilots), with no specific obligations under the regulation.

Who enforces this in Spain

Supervision falls to AESIA (the Spanish Agency for the Supervision of Artificial Intelligence), based in A Coruña, which published sixteen guides in December 2025 and has had full sanctioning powers since August of that year. The AEPD (Spanish Data Protection Agency) retains responsibility for biometrics and personal data. Bear in mind that the AI Act does not replace anything: it comes on top of the GDPR, the ENS (Spain's National Security Framework), ISO 27001 and, in financial services, DORA. Spain's transposition of NIS2 was still awaiting publication in the BOE (Spain's Official State Gazette) in mid-2026, with a second formal notice from the Commission along the way.

The table is useful for the thing that saves the most time: not doing the same work three times. If you already have a certified management system, most of the ISO 42001 effort is done, and the Article 27 fundamental rights impact assessment can be combined with the GDPR data protection impact assessment into a single exercise with three outputs.

The architecture that holds all of this up

None of the above holds up if there is no single place that usage passes through. That place is an AI gateway: a proxy through which requests to the models travel and where identity, data loss prevention, filtering, logging and cost control are applied. It is the same reasoning that led companies to put an egress proxy on corporate networks twenty years ago.

Layers of a corporate AI gateway: identity and authorization with SSO and quotas; data loss prevention on input; prompt injection detection filters; model routing with a no-training clause and data residency; tool permissions with least privilege, short-lived credentials and an allowlist of MCP servers; output validation, treating output as untrusted input; and logging of prompts, responses, tools and model versions with a defined retention period.

There is one piece that is almost always forgotten: retrieval indexes. When you build a system that queries your documents, that index either inherits the source permissions or it doesn't. If it doesn't, you have just built a search engine that answers anyone with the contents of the executive team's folder. Segregating indexes with inherited access control is not a refinement: it is the difference between a useful tool and a data leak with a built-in search box.

A roadmap in three phases

1. 0-30 days — See what is already there
   Uncover shadow AI with the cloud access control and data posture tools you already have. Build an initial inventory with owner, data processed and vendor. Publish a short, provisional acceptable use policy. Make out-of-band verification mandatory for transfers, which is the most cost-effective mitigation on the whole list. Appoint an AI lead with real authority and confirm the Article 4 AI literacy requirement, which is already mandatory.
2. 30-90 days — Put the control in the middle
   Classify use cases by risk under the AI Act. Deploy the gateway with data loss prevention and logging, which on its own enables half of the security indicators. Define the pre-production gates and who decides at each one. Review the contracts of the vendors in use, with the no-training clause as a red line. Run a first red teaming exercise against critical systems. Set the baseline for the three groups of indicators.
3. 90-180 days — Make it sustainable
   A reference architecture for agents: least privilege, short-lived credentials, human confirmation for anything irreversible and an allowlist of tool servers. Segregation of retrieval indexes. Integrated impact assessments for anything high risk. A board dashboard of five to seven metrics. And the decision on ISO 42001, which makes sense if AI is central to your product or if it starts appearing in your customers' tender requirements.

Order matters: without an inventory, classification is impossible, and without a gateway there is no way to enforce any policy.

Measuring without fooling yourself: three families that don't mix

The most common mistake in AI dashboards is putting adoption, risk and return in the same table. High adoption can be hiding risk, and a positive return can be ignoring the cost of reviewing what the model produces. That is why they are split into three blocks with different owners.

Why most pilots go nowhere

The most widely shared statistic of 2025 came from MIT: 95% of generative AI pilots produced no measurable impact on the P&L. It should be handled with care, because it is a preliminary, non-peer-reviewed study, but the direction is confirmed by independent sources that measure different things.

Four studies, four methodologies, the same direction. The last bar is the one worth looking at: the 26% that do succeed.

The cause does not lie in the model. BCG sums it up in a ratio that explains almost every failure we see: 10% of the effort goes into algorithms, 20% into technology and data, and 70% into people and processes. Those who invest the other way around end up with a brilliant pilot that nobody uses.

The test that separates the 5% from the 95%. If a use case cannot demonstrate a return within two quarters — with a control group, before-and-after measurement and after subtracting the cost of human review — retire it. A use case that looks profitable but requires reviewing 100% of its output probably isn't.

Fraud already uses AI, and it works all too well

Part of this issue depends not on your architecture but on the attacker's. In January 2024, an employee of the engineering group Arup in Hong Kong made fifteen transfers totaling some $25.6 million after a video call in which the CFO and several colleagues were deepfakes. Nobody did anything stupid: the process simply did not account for the possibility that a familiar face on a video call could be fake.

$25.6M

transferred by an employee after a video call with deepfakes (Arup case, Hong Kong, January 2024)

$893M

in losses from complaints listing AI as a descriptor (FBI IC3 2025, across 22,364 complaints)

16%

of breaches involved attackers using AI (Of those, 37% AI-generated phishing and 35% impersonation)

Voice and video impersonation has gone from a lab demo to a line item in the FBI's annual report.

The control that would have stopped the Arup case costs one meeting. Mandatory out-of-band verification for any transfer above a threshold, through a different channel from the one the request came in on, with a waiting period for large amounts. And an explicit cultural rule: whoever calls to verify is never in the wrong, even if the CEO is on the other end. The process should protect the person, not expose them. And if you want to know how your staff would respond, you can test that with phishing simulations.

Where to start tomorrow

If I had to pick five decisions that change the outcome, these would be the ones, and every one of them hinges on a concrete threshold rather than an opinion:

1. If you detect shadow AI among more than 10% of your workforce, the priority is the gateway and channeling demand, not a ban.
2. If any use case falls under Annex III, trigger the impact assessment and start on the technical documentation now: December 2027 seems far off until you count it in quarters.
3. If you provide a general-purpose model or train your own models, Articles 53 and 55 have applied to you since August 2025.
4. If you operate in the financial sector, DORA governs a large share of these controls and arrives before the AI Act.
5. If a pilot cannot demonstrate a return within two quarters with a control group, retire it without ceremony.

None of this requires a two-year program. It requires knowing what is there, putting it behind a control and measuring it honestly. We come in at one of three points depending on where you are: AI governance and secure use when what is missing is the framework and the technical control; AI and LLM penetration testing when you already have something in production and it needs to be attacked before someone else does; and AI Act compliance when the pressure comes from compliance or from a customer who requires it in the contract.

If you don't know which of the three to start with, that is exactly the half-hour conversation worth having: tell us about it and we'll tell you what we would do in your position, including when the answer is to wait.

Related service

AI governance and secure use

Topics

#Artificial-Intelligence #AI-Act #Governance #Shadow-AI #LLM #Compliance #AI-Agents

Keep reading

• Can I upload this to AI? Classify the data before you paste it
• How an AI application is attacked: prompt injection and tool-using agents
• European compliance calendar 2026-2030: CRA, AI Act, Data Act and everything still to come
• Docker Model Runner vs. Ollama
• Can emojis hack AI models?

Sources

• Regulation (EU) 2024/1689 — Artificial Intelligence Act
• OWASP Top 10 for LLM Applications
• MITRE ATLAS — threat matrix for AI systems
• NIST AI Risk Management Framework
• IBM — Cost of a Data Breach Report
• AESIA — Spanish Agency for the Supervision of Artificial Intelligence

Review how you use AI today