An employee pasting source code into an approved coding assistant is not automatically an incident. A finance team using an unapproved public chatbot to summarize customer data may be. The difference is not simply the model name or whether AI was involved. It is the context of the behavior. To understand how to baseline AI behavior, security teams need evidence of what normal AI use looks like across their organization before they can reliably identify what is risky.
For most enterprises, that evidence does not exist yet. AI adoption has spread faster than inventories, policies, and security controls. Employees use browser-based assistants, embedded SaaS features, developer tools, APIs, and locally configured models. A policy may describe what should happen. A behavioral baseline shows what is happening.
Why AI behavior needs its own baseline
Traditional security baselines often focus on devices, identities, network activity, and application access. Those controls still matter, but AI introduces a different class of visibility problem. The same user can interact with multiple models through different interfaces, send information in prompts rather than files, and receive outputs that influence operational decisions without generating a conventional security event.
A useful AI baseline answers operational questions: Which AI services are being used? Who uses them? What type of data or task is involved? Is the use sanctioned? What is typical for a user, team, role, or business unit? And when does activity depart from that pattern?
The goal is not to declare all unfamiliar activity malicious. New AI usage can reflect legitimate experimentation, an approved pilot, or a changing job responsibility. The goal is to reduce uncertainty. Security teams need enough context to triage deviations without treating every prompt, model, or user as a separate investigation.
Start with discovery, not policy assumptions
A baseline built from an approved-tools list will be incomplete from the start. Security teams should first discover actual AI usage across the enterprise, including public tools, enterprise platforms, AI features inside existing SaaS applications, developer environments, and direct model API access.
This discovery should connect activity to identity, device, department, application, and environment where possible. A record that only says a connection was made to an AI domain provides limited investigative value. A record that shows a developer in a production engineering group used a new model endpoint from an unmanaged device, outside their normal pattern, is meaningfully different.
Visibility should also distinguish between model providers and the products built on them. Employees may use the same underlying model through a sanctioned enterprise workspace, a personal account, a third-party browser extension, or an embedded tool. These paths can have different retention, access, contractual, and data handling implications.
Discovery is ongoing work, not a one-time inventory. New models, features, plug-ins, and AI-enabled SaaS capabilities appear continuously. If the collection process cannot keep pace with adoption, the baseline will age quickly and create false confidence.
Define behavior at the right level
There is no single enterprise-wide definition of normal AI behavior. A marketing team may regularly use generative AI for copy drafts. A legal team may use an approved research platform for document analysis. A software engineering team may send code context to a sanctioned assistant. These activities may all be normal within their own operating context while looking unusual in aggregate.
Build baselines across several layers:
- Organization level: Common providers, approved platforms, total usage volumes, and broad changes in adoption.
- Business unit and team level: Typical tools, workflows, data sensitivity, and expected usage windows.
- Role and user level: Individual patterns that materially differ from peers or from the user’s own history.
- Environment level: Differences among managed endpoints, developer workstations, production systems, test environments, and personal devices.
These layers prevent a common failure mode: comparing every employee against an enterprise average. A security architect who interacts with model APIs all day should not be measured against a payroll specialist. Conversely, a payroll specialist suddenly using a personal AI account to process employee records deserves closer review even if total AI usage is low.
Establish the signals that matter
A baseline is only as useful as the signals it captures. Focus on observable attributes that help an analyst explain activity, not vanity metrics such as total prompt volume alone.
First, track the application, provider, model, account type, and access path. An approved enterprise tenant and a consumer account are not equivalent, even when they share a brand name. Next, capture the user and organizational context: identity, department, role, device posture, and whether the activity originated from a managed environment.
Then assess interaction context. Depending on the controls and telemetry available, this can include data classifications, prompt or upload indicators, API calls, external connectors, files accessed, and actions taken after an AI interaction. Security teams do not need to collect every word an employee enters to create a useful baseline. They do need enough evidence to identify whether sensitive information, credentials, source code, customer records, or regulated data may be involved.
Time and sequence also matter. A burst of activity after normal hours may be expected for a global engineering team. The same pattern from a user who has never used AI before, paired with a new public service and a large data transfer, is a stronger signal. Behavioral baselining is about combinations of events, not isolated indicators.
How to baseline AI behavior without creating noise
Begin with an observation period long enough to capture normal work cycles. For many organizations, 30 days provides an initial picture, while 60 to 90 days produces a more reliable baseline across month-end work, project cycles, travel, and team variation. Do not wait for perfect data. Establish an initial reference point, label confidence levels, and refine it as visibility improves.
During this period, classify discovered tools into practical categories: approved, tolerated but unreviewed, prohibited, and unknown. These categories should reflect real security and legal decisions, not a generic vendor reputation score. An unreviewed tool used for public research has a different priority from an unreviewed tool receiving customer data.
Next, identify expected patterns by peer group. Review what each group uses, the usual frequency, typical environments, and known business purpose. Document exceptions that are already understood, such as an approved pilot or a specialist team with temporary access to a model API. This makes later investigations faster because analysts do not need to rediscover business context during every alert.
Finally, tune detection around meaningful deviations. Examples include a first-time use of an unapproved service by a sensitive-data team, a user switching from an enterprise tenant to a personal account, an unusual increase in file uploads, access from an unmanaged device, or new AI activity tied to a privileged identity. The right threshold depends on the organization’s risk tolerance and available response capacity. A small security team may begin with fewer, higher-confidence alerts. A mature SOC may investigate a broader set of weak signals for trend analysis.
Treat baselines as evidence, not enforcement
A baseline should inform policy and control decisions, but it should not be mistaken for permission. Widespread use of an unapproved tool does not make that tool safe. It may indicate an urgent business need, a gap in the approved toolset, or a failure to communicate available options. Each possibility calls for a different response.
This is where security visibility supports better decisions. If a team is repeatedly using a public AI tool for a legitimate workflow, leadership can assess whether to approve an enterprise alternative, provide a sanctioned capability, restrict the risky path, or redesign the process. Without usage evidence, organizations often default to broad restrictions that employees bypass or policies that do not reflect reality.
The same principle applies to investigations. A deviation from baseline should open a question, not automatically assign blame. Analysts should be able to see the user, tool, interaction history, relevant data indicators, peer behavior, and prior exceptions in one investigation context. Explainable context is what turns an alert into a defensible decision.
Keep the baseline current as AI adoption changes
AI behavior changes faster than many traditional technology patterns. New model releases, embedded assistant features, acquisitions, reorganizations, and policy changes can all shift normal behavior. Revisit baselines after major business or technology events, and review them on a regular cadence even when no major change is expected.
Measure whether the baseline is improving security operations. Useful indicators include the percentage of AI tools with a known status, the share of AI activity attributed to an identity and business context, the number of meaningful deviations investigated, recurring high-risk workflows, and the time required to determine whether an alert needs escalation. More alerts are not proof of better security. Better context and faster, more consistent decisions are.
ModelSight approaches this problem from the visibility layer: discover real AI usage, observe behavior in context, identify suspicious deviations, and give security teams the evidence to act. Control becomes more precise when it is based on observed behavior rather than assumptions.
The most useful baseline is not a static report that says which AI tools existed last quarter. It is a living operational reference that helps your team recognize when AI use changes, understand why it changed, and respond before uncertainty becomes exposure.