Enterprise security programs spent a decade refining controls for SaaS, identity, and network pathing. Generative and agentic AI break that model in two directions at once: employees bring external tools into everyday workflows, and engineering teams ship applications that reason, retrieve, and act with privileges that look nothing like a traditional service account.
That dual pressure is why AI Security Platforms (AISP) are moving from innovation-lab vocabulary into board and risk-committee language. The gap is not a missing slide deck. It is the absence of a control system that treats AI both as a channel people use and as a class of applications organizations build.
Why this is showing up in board language now
According to Gartner, by 2028 more than 50% of enterprises will use AI security platforms to secure third-party AI service usage and protect custom-built AI applications. Gartner also projects that fifty percent of enterprise cybersecurity incident response efforts will focus on incidents involving custom-built AI-driven applications by 2028.
Read that again as a privacy and security practitioner. Half of future IR work may not resemble ransomware or a phished mailbox. It may look like an agent that over-shared, a model that ingested the wrong corpus, or a plugin that shipped without a privacy impact assessment.
Gartner also named AI Security Platforms among its top strategic technology trends for 2026. Secondary write-ups of that trend work, including Cato Networks’ summary of Gartner’s AISP trend, describe the same adoption curve: a small slice of enterprises in the mid-2020s, majority territory by 2028.
You do not need a crystal ball. You need architecture that assumes AI is already in production—often unlabeled in the risk register.
Two pillars for explaining AISP to non-security leaders
When security, privacy, product, and risk owners align stakeholders, tool bingo rarely helps. A clearer model uses two buckets that map cleanly to ownership and budget.
1. AI Usage Control (AIUC)
This is the “who is using what, with which data” problem.
Across many enterprises, the pattern looks familiar:
- Knowledge workers pasting confidential material into consumer chat tools
- Sales or marketing teams connecting CRMs to copilots without a data-flow review
- Engineering spinning up “temporary” model API keys for side projects
- Vendors quietly adding AI features into SaaS products approved before those features existed
AIUC is policy plus enforcement. Acceptable use alone is not enough. Mature programs combine identity-aware controls, data classification boundaries, logging, and the ability to block high-risk destinations when personal information or regulated data is involved.
In privacy and governance reviews, inventory is often the whole ballgame. If an organization cannot list approved AI services and the data categories allowed in each, privacy impact assessments become aspirational rather than operational.
2. AI Application Security (AIAS)
This is the “we built it, now it can fail in new ways” problem.
Custom AI apps and agents introduce failure modes traditional application security only half covers:
- Prompt injection and tool abuse
- Training or retrieval data leakage
- Over-privileged service accounts acting on behalf of users
- Insecure plugin and connector design
- Model and agent actions that look “authorized” solely because a token was valid
AIAS sits closer to application security, threat modeling, and secure SDLC—with AI-specific tests layered in. If a team can ship an agent that reads email, writes tickets, and calls internal APIs, security review must treat that agent like a new class of privileged user, not a clever UI wrapper.
Illustrative patterns in privacy and risk work
Strong AISP programs rarely begin with a platform RFP. They begin with concrete operational patterns.
Pattern one: shadow AI. An analyst uses a free tool because the approved option feels slow. The content includes unpublished product plans or customer personal data. No DLP signature fires because the traffic looks like ordinary HTTPS to a popular domain.
Pattern two: approved tool, weak configuration. An enterprise license exists. Logging is disabled for “performance.” Retention settings do not match investigation or hold needs. The privacy notice says one thing; vendor subprocessors and model-training clauses say another.
Pattern three: the agent that works too well. An internal assistant receives broad read access “for accuracy.” It summarizes a repository it should never have seen. Nobody malicious. The permission model was optimistic.
These patterns explain why AISP conversations now sit next to Zero Trust and CASB discussions—not only next to innovation labs.
A practical sequence without boiling the ocean
Platform selection is easier once the program sequence is clear. A durable path for the next quarter looks like this:
- Inventory what people already use. Browser extensions, SaaS AI features, API keys in secrets managers, and team accounts on corporate cards often outrun official catalogs.
- Classify data that must never leave controlled channels. Customer PII, employee data, financial records, trade secrets, and materials under formal hold are non-negotiable boundaries.
- Separate usage policy from build policy. Employees using third-party AI is not the same control set as engineers shipping agentic workflows.
- Wire logging to incident response. If half of future IR load involves AI apps, playbooks need AI-specific evidence: prompts, tool calls, model versions, data sources, and who approved the integration.
- Put privacy and security reviews early. A privacy impact assessment after launch is damage control. For AI features, purpose limitation, retention, and data minimization belong before the first production prompt.
- Map platform capabilities to AIUC and AIAS. Prioritize central visibility, policy enforcement, and protections against AI-native abuse. Gartner’s public framing centers on visibility, usage policy, and guardrails across third-party and custom AI.
Common failure modes (industry patterns)
Programs stall when they confuse artifacts with controls.
Acceptable use treated as enforcement. A GenAI policy PDF is necessary hygiene. It is not a control. Controls are technical and operational: identity binding, destination filtering, DLP, monitoring, and response.
Innovation speed as a free pass. Fast-track integrations that skip security and privacy review train the organization to route risk around the control plane. Speed and governance are not opposites; ungoverned speed simply moves residual risk into production.
Static vendor assessments. Collaboration suites and productivity platforms ship new AI features mid-contract—meeting summaries, chat memory, connectors into systems never assessed for that purpose. Continuous third-party review and contract language matter as much as the initial questionnaire.
Single-pillar investment. Buying only usage monitoring while ignoring agent privileges—or funding appsec for custom models while shadow tools run unchecked—leaves a blind side that leadership will rediscover during an incident.
Where CISSP thinking helps
This is classic risk management and security architecture with new objects in scope.
- Asset management now includes models, agents, prompts, embeddings, and connectors
- Identity and access management must cover non-human actors with real privileges
- Logging and monitoring need AI-aware telemetry
- Incident response needs scenarios for data exfiltration via prompts and automated actions
- Third-party risk must re-score vendors when AI features appear mid-contract
If a security program still treats AI as a novelty pilot, residual risk is already in production. It simply is not labeled that way in the register.
Domain alignment sits primarily in Security and Risk Management, with strong ties to Security Architecture and Engineering (control design for new system types), Identity and Access Management (non-human identities), and Security Operations (detection and IR for AI-mediated events).
Actionable takeaway
This week, draft a one-page map with two columns: AI Usage Control and AI Application Security.
Under usage, list the top five AI services people actually touch and the data types allowed in each. Under applications, list every internal AI feature or agent in production or pilot, the privileges it holds, and whether incident response could reconstruct its actions tomorrow morning.
If either column is empty or full of “unknown,” the organization does not yet have a platform problem. It has an inventory problem. Fix that first. Platforms amplify control; they do not invent visibility a program refused to collect.
Then take that map to the next risk or architecture review. Ask one question: which gaps would still surprise us if Gartner’s 2028 incident-response prediction arrived early?
That conversation is more useful than another slide titled “AI strategy.”