Buyers use "AI" to mean two different things, and they don't know they're doing it. Predictive AI scores, classifies, and flags anomalies. Generative AI writes, synthesizes, and produces. Most enterprise security and productivity products now run both, often in the same dashboard. The seller who can name the difference, and explain why one can substitute for the other but not vice versa, controls the frame for the rest of the call. That asymmetry is the thing worth knowing. Everything else follows from it.
Predictive AI
What it is: A model trained to classify inputs or forecast outcomes by learning patterns from labeled historical data.
What it does: Produces a score, a label, or a probability. Fraud risk on a transaction: 0.94. Likelihood this user account is compromised: high. This log event: anomalous. The output is always a number or a category. Never prose, never explanation, never something the model invented. It answers the question it was trained to answer, and only that question.
In enterprise security, predictive models are the workhorses behind fraud detection, churn scoring, network anomaly detection, and user behavior analytics. They run continuously, at low latency, on structured data. A well-tuned fraud model at a major bank might evaluate millions of transactions per hour and flag a fraction of a percent for review. The model doesn't know why it flagged the transaction. It knows the transaction looks like other transactions that turned out to be fraud.
Who's behind it: The lineage runs through decades of academic machine learning — support vector machines, random forests, gradient boosting — into applied ML teams at companies like Google, Amazon, and the fraud-detection specialists. In enterprise security, vendors like Darktrace, Securonix, and the ML layers inside major SIEM platforms have been shipping predictive models for years. Most production predictive models today are gradient-boosted trees or neural classifiers, not the transformer architectures that power generative AI. The underlying math is different, and that difference matters.
What makes it distinct: It has one job. That specificity is its strength — a model trained on ten years of fraud data, with carefully engineered features and a labeled dataset, will outperform a general-purpose language model on that specific task. It's also its ceiling. Ask it to do something outside its training distribution and it doesn't adapt; it either fails silently or produces a confident wrong answer. The model cannot be prompted. There is no interface for "do something different."
IDAM Callout: Session Risk Scoring
Predictive AI is the engine behind behavioral risk scoring in identity platforms — the kind of continuous session evaluation that compares a user's current activity against their historical baseline and surfaces an anomaly score. The analogy holds cleanly: same mechanism, same output type (a score that triggers a policy). Where it breaks: identity risk scores are typically tuned by security teams with labeled incident data; a generative model doing the same job would be slower, less auditable, and harder to explain to a compliance reviewer. In a buyer conversation, this framing is useful: "your existing risk engine is already predictive AI — it's not going away when you add a generative copilot. They're doing different things."
Generative AI
What it is: A model trained to produce new content — text, code, images — by learning the statistical structure of its training data.
What it does: Given a prompt, it generates an output that fits what it learned. In enterprise contexts: drafts policy documents, writes and explains code, summarizes security logs in plain English, answers questions about internal documentation, generates synthetic test data. The output is always new — the model is not retrieving stored text, it's constructing a response token by token based on learned probability distributions over language.
The modern generative AI landscape is dominated by large language models built on the transformer architecture — GPT-4 from OpenAI, Claude from Anthropic, Gemini from Google, Llama from Meta. Enterprise deployment happens through APIs and through embedded copilot features in products from Microsoft, Salesforce, ServiceNow, and increasingly every major security vendor. If a product launched in the last eighteen months and has a text box that answers questions, there's a generative model behind it.
Who's behind it: The foundational architecture — the transformer, introduced in Vaswani et al.'s 2017 paper "Attention Is All You Need" — came out of Google Brain. The scaling insight that made large language models work came from OpenAI's GPT series and was then replicated and extended by every major AI lab. The enterprise deployment infrastructure is newer and still maturing: fine-tuning pipelines, retrieval-augmented generation, context window management. The research is moving fast enough that capabilities documented six months ago may already be outdated.
What makes it distinct: It wasn't trained to answer a specific question. It was trained to model language, which means it can be directed toward almost any language task — including tasks that look like classification. That flexibility is the thing that changes the competitive calculus for specialized models, and it's worth understanding mechanically before you try to explain it in a room.
IDAM Callout: AI-Assisted Policy Authoring
Generative AI shows up in identity platforms as the layer that helps administrators write, explain, and troubleshoot policy — natural language interfaces for access rules, workflow generation, log summarization. The analogy holds for the authoring step: the model drafts, the human reviews, the platform enforces. Where it breaks: generative models don't enforce policy. They produce text that describes policy. The enforcement layer is still deterministic — a rule engine, an access control list, a conditional access policy. In a buyer conversation: "the copilot that writes your access policy is generative AI; the engine that enforces it is not, and that distinction matters when you're explaining your compliance posture."
The Comparison: Trait-Led Analysis
Structure note: I'm using trait-led analysis rather than a flat A/B table or scenario mapping. The reason is that the central asymmetry (generative can do predictive, predictive cannot do generative) only becomes visible when you examine the underlying mechanism of each trait, not when you list them side by side. A table would flatten the asymmetry into a row. Walking through four traits surfaces why the asymmetry exists.
Output type. Predictive models produce a score or label. Generative models produce content. Classification is actually a subset of content generation: "output the word 'fraud' or the word 'legitimate'" is a perfectly valid generative task. The reverse doesn't hold. A logistic regression model cannot be prompted to write a paragraph. It has no language interface. That's where the capability gap opens.
Training objective. Predictive models are trained discriminatively — they learn a boundary between classes, optimizing for accuracy on a specific labeled dataset. Generative models are trained to predict the next token in a sequence, over a vast vocabulary, across an enormous corpus. That training objective is why generative models can be redirected: they learned a general model of language, not a specific decision boundary. You can ask a language model to classify sentiment, summarize a document, or detect whether an email is phishing, because all of those are language tasks, and the model learned language. You cannot ask a fraud classifier to do any of those things, because it learned a boundary, not a language.
That's why "just use GPT-4 for everything" wins internal procurement arguments. The flexibility is real. In a narrow, high-stakes domain with years of labeled training data, a purpose-built model will outperform a general-purpose LLM. The LLM can do the task; it just won't do it as well. That distinction is the one worth making in the room.
Failure modes. Predictive models fail in two directions: false positives (flagging legitimate transactions as fraud) and false negatives (missing actual fraud). These failures are measurable, tunable, and auditable. You can look at the confusion matrix. Generative models fail differently. They hallucinate, producing confident, fluent, wrong answers. They can be manipulated through prompt injection. They degrade on inputs that fall outside their training distribution in ways that are harder to detect because the output still looks like coherent text. Neither failure mode is worse in the abstract. They're different, and conflating them produces bad risk assessments.
Cost and latency. Predictive models are fast and cheap at inference time. A gradient-boosted tree evaluating a transaction takes microseconds. A large language model generating a response takes seconds and costs meaningfully more per query. For high-volume, low-latency tasks (fraud scoring, anomaly detection, real-time access decisions), predictive models have a structural advantage that generative models won't close through capability improvements alone. For low-volume, high-complexity tasks (drafting a policy, explaining an alert, answering a novel question), the latency and cost profile of generative models is acceptable and the flexibility advantage is decisive.
Most enterprises will run both, because the tasks that benefit from each type don't overlap as much as the "just use GPT-4 for everything" argument implies. The displacement is real in some categories (text classification, intent detection, document routing) and overstated in others.
IDAM Callout: The Hybrid Product Reality
Identity platforms increasingly run both model types in the same product: a predictive model scores session risk continuously; a generative model explains why a session was flagged, in plain English, to the analyst reviewing the alert. These are not competing capabilities — they're complementary layers. Where the analogy breaks down is governance: predictive model outputs are typically logged, auditable, and explainable through feature importance. Generative model outputs are harder to audit and may vary across identical inputs. In a buyer conversation about AI governance, this distinction matters: "you need different oversight mechanisms for each type, and most AI governance frameworks don't separate them clearly yet."
How to Say This in the Field
The conflations below are real. Most of them come from buyers who have been pitched "AI" as a single category for years and are now trying to make procurement decisions with vocabulary that isn't precise enough to support them. Your job is to introduce precision without making the buyer feel corrected.
| Don't say | Do say | Why it matters |
|---|---|---|
| "AI" (when you mean one specific type) | "Predictive model" or "generative model," depending on which one you mean | Buyers use "AI" to mean both; using the specific term forces a useful clarification |
| "We already have AI" (when the buyer means a fraud score) | "You have a predictive model for that use case — that's different from what a generative model would add" | Prevents the buyer from treating existing ML as a reason not to evaluate new capabilities |
| "GPT-4 can replace your fraud model" | "A generative model can do classification, but a purpose-built model will outperform it in a narrow, high-stakes domain where you have labeled training data" | The asymmetry is real but bounded; overclaiming it loses credibility |
| "Generative AI hallucinates, so it's not reliable for security" | "Hallucination is a generative AI failure mode; your anomaly detection model fails differently — false positives and false negatives, not fabrications. Different risks, different mitigations" | Treating hallucination as a disqualifier conflates failure modes and shuts down a useful conversation |
| "Predictive AI is more accurate" | "Predictive models are more accurate in the specific task they were trained for; generative models are more flexible across tasks" | "More accurate" without a specific context is meaningless and will get challenged |
| "You need to train it on your data" (about an LLM) | "You can fine-tune a generative model on your data, but most enterprise use cases start with prompting or retrieval — no training required" | Overstating the implementation burden kills deals that would otherwise close |
| "The AI makes the decision" | "The predictive model scores the risk; the decision is made by a policy rule or a human reviewer" | Buyers with compliance requirements need this distinction; conflating scoring with deciding creates audit problems |
| "Generative AI is just a chatbot" | "A chatbot is one interface for a generative model; the same model can classify text, generate code, or summarize logs depending on how it's prompted" | Underselling generative capability is as costly as overselling it |
| "We're not ready for generative AI yet" | "You're probably already running generative AI in products you've deployed — the question is whether you're governing it" | Most enterprises are past the adoption decision; the conversation is now about governance |
| "AI is AI" | "These are different architectures with different failure modes — conflating them in a procurement conversation will cause problems when the contract hits legal review" | Sounds reasonable until someone has to write the security addendum |
The last row is the one worth memorizing. "AI is AI" is the statement that ends useful conversations. The buyer who says it isn't being lazy — they're using the vocabulary they have. Your job is to give them better vocabulary before the conversation requires it.