This guide brings together all the AI and cybersecurity expertise we have organized to address this situation, divided into three categories that this guide presents one by one: governance and regulatory compliance, available security services, and the technical section covering AI architectures and their associated risk factors. Each section below summarizes the key points and provides a link to the corresponding full guide for further details.
One principle runs throughout this guide and deserves to be established before we even delve into the three categories it comprises: ensuring AI security in the workplace is never a purely technical or purely organizational issue. It is the interplay of both—governance that establishes the framework, technical controls that enforce it, and a shared understanding of risks that ensures this interplay remains sustainable over the long term—that distinguishes successful approaches from those that remain mere declarations of intent.
Why AI Security Has Become a Topic in Its Own Right
Existing security frameworks were not designed for a component capable of generating text probabilistically, being manipulated by natural language itself, or acting autonomously across multiple systems in a single session. Three recent developments illustrate why this issue can no longer be treated as a minor extension of traditional application security.
First, the growing autonomy of deployed systems: in a short period of time, we have gone from a conversational assistant that answers a single question to agents capable of planning multiple steps, invoking a sequence of tools, and acting within the permissions granted to them—sometimes without human validation at every step.
Furthermore, the pace of adoption has outstripped that of the governance mechanisms intended to regulate it: an employee can now implement an AI application without going through the IT department, unlike traditional business software, which generally requires a more visible purchasing or installation process.
Finally, regulatory convergence (GDPR, EU AI Act, NIS2, sector-specific frameworks) now requires a cross-referencing approach that most organizations had not previously had to undertake, as each piece of legislation has its own deadlines, supervisory authorities, and penalties.
These three developments explain the very structure of this guide: they justify devoting an entire category to governance and another to all technical risks (architectures, attack vectors, and commercially available tools), which are now inextricably linked.
The scope of a phenomenon that has yet to be fully mapped
The available studies agree on one point, even when they differ on the exact figures due to different methodologies: The gap between the actual use of AI in businesses and its formal governance remains significant in 2026, 10% of employees report the existence of an AI policy or ethics committee , including in organizations that consider themselves cautious on this issue.
This discrepancy has a direct impact on how to approach this guide: most organizations do not need an immediate, comprehensive audit to begin taking meaningful action. Even a partial mapping of actual usage patterns, cross-referenced with the most relevant risk vectors for the architecture currently in use, is often sufficient to identify the two or three priorities that will yield the greatest impact with the least effort. This is the approach this guide seeks to reflect in its very structure: rather than a collection of exhaustive content, it presents three categories designed to allow organizations to start at the most relevant point based on their initial situation.
1. Governance Audit, DLP, and AI Compliance
This is the foundation of any structured AI security approach, and currently the most dynamic area from a regulatory standpoint. It addresses organizational questions (who makes decisions, who is responsible, how to draft a legally enforceable terms of use policy) as well as specific compliance issues: what the EU AI Act actually requires following the adoption of the Digital Omnibus at the end of June 2026, what is the status of France’s transposition of NIS2, how to align the GDPR and the EU AI Act without duplicating efforts, and how to structure logging and identity management systems that will stand up to an audit.
The Shadow AI (the use of AI tools by employees outside any approved framework) plays a central role here, as it is often the first visible sign of absent or poorly calibrated governance, even before other technical components come into play. A blanket ban on unapproved tools fails almost without exception, driving usage into hidden channels rather than eliminating it. Effective governance approaches offer a validated alternative that is at least as accessible as the consumer-grade tool they seek to replace, rather than relying solely on bans.
→ See our comprehensive guide to AI governance in business.
2. AI Services
Once the governance framework is in place, the question becomes an operational one: how can we practically assess and test the security of deployed AI systems, and at what cost? This category covers five complementary services, in an order that matters: mapping to determine what is actually deployed, risk assessment to set priorities, auditing to verify configuration, and penetration testing to actively test resilience. It also addresses the practical questions that often precede the engagement of a service provider: how much it costs depending on the level of detail required, and which checklist to use internally before—or in addition to—engaging an external provider.
For example, a standard application penetration test does not, by default, cover AI-specific attack vectors unless the methodology has been explicitly extended to include these scenarios: this is a key distinction to consider when selecting a service provider, between an AI security audit and a standard penetration test
→ See our comprehensive guide to AI security services.
3. AI Penetration Testing: Expertise Based on Proven Cybersecurity Fundamentals
Securing AI is not a discipline entirely separate from traditional cybersecurity, but rather an extension of its principles to a new type of component. AI penetration testing draws directly on the proven methodology of our penetration testing, extended to specific scenarios such as prompt injection, jailbreaking, or knowledge base poisoning
This continuity has an important practical implication: an organization that has already invested in a mature cybersecurity framework (regular audits, penetration tests, formalized risk governance) has a foundation that can be largely reused to structure its AI security, rather than having to start from scratch. Conversely, an organization that is still relatively immature in terms of general cybersecurity will often benefit from addressing both areas in a coordinated manner, as AI security cannot sustainably compensate for broader gaps in the company’s information security.
4. Architectures & Risk Factors
An AI system in production rarely consists of just a single component: LLM, RAG and vector databases, function calling, the MCP protocol for agent orchestration, MLOps infrastructure, and model serving—all accessible via off-the-shelf tools (ChatGPT, Copilot, Claude, Gemini, and Mistral for assistants; GitHub Copilot, Cursor, Windsurf for code; Ollama, Open WebUI, LM Studio for self-hosting)—which are not all equal from a security standpoint. This single category deliberately groups together the architectural building blocks and the eleven associated attack vectors (prompt injection and jailbreak for LLMs, RAG poisoning for vector databases, inherited permissions for MCP and agents, extraction and inversion for the trained model, and slopsquatting for the development pipeline) because most recently documented incidents occur precisely at the interfaces between these building blocks, rather than within any single isolated component.
The principle underlying this category can be summed up in a single sentence that applies to all the building blocks it covers: an agent or connector operates with the permissions granted to it, and any successful operation performed by that agent automatically inherits this elevation of privileges. A further observation applies across all associated attack vectors: excessive human trust in the outputs of an AI system remains the most systematically exploited weakness—more so than the technical sophistication of the attack itself. This means that a significant portion of risk reduction does not require expertise in machine learning, but rather the rigorous application of already known security principles.
→ See our comprehensive guide to AI architectures and risk factors.
Where to Start, Depending on Your Situation
Given these three categories, the most appropriate order in which to read them depends on each organization’s starting point, rather than on a single approach that applies to all.
The profiles below cover the most common situations, without claiming to cover every possible scenario: an organization may well find that it fits several profiles at once, particularly when different internal teams are at different stages of maturity in this area.
- For an organization that is new to the subject and does not yet have a formalized AI security framework in place, the most natural starting point is the “services” category, which addresses budget and checklist considerations before delving into technical details.
- For an organization that already has AI tools in use but no formalized governance framework, the priority is generally the governance category (specifically, mapping shadow AI and establishing a usage policy) alongside initial security measures for the tools already deployed, which are covered in the architectures and risk vectors category.
- For a technical team designing or deploying an AI system (RAG, agent, MCP integration), the “Architectures and Risk Vectors” category is the most directly actionable starting point, since it links each technical component to the attack scenarios that must be anticipated before the system goes live.
- For an organization that has already established the basic framework and is seeking to validate the actual robustness of its systems, AI-based security services—particularly penetration testing—enable it to move from declarative compliance to a concrete demonstration of resilience against realistic attack scenarios.
- For an organization facing a specific regulatory deadline —such as an upcoming client audit, a certification target, or an anticipated inspection—the governance category remains the most direct starting point, but it should be quickly supplemented by a risk assessment service: documentary compliance alone, without underlying technical validation, remains vulnerable to the first incident that contradicts the statements made on paper.
Frequently Asked Questions
Which category should you start with if you don't know where to begin?
Should we address governance before the technical aspects, or the other way around?
Does this guide cover both large companies and small and medium-sized enterprises?
How can you tell if an AI security approach is truly comprehensive?
Will this guide be updated to reflect new regulations and technologies?
Structuring Your End-to-End AI Security Approach
Our experts guide you through every step of this process—from the initial assessment to technical validation through penetration testing—using an approach tailored to your level of maturity and your industry. Would you like to discuss your project or assess your needs? Contact our experts.