What should organisations do after an employee uses generative AI with business data?

Why This Matters for Security Teams

Once an employee pastes business data into a generative AI tool, the issue is no longer just usage policy. Security teams need to determine whether that prompt, attachment, or pasted context created a disclosure path that bypassed approved identity, logging, or retention controls. That review should focus on what data moved, where it went, and whether the system could later be queried or reused outside governance.

This matters because AI interactions often sit between traditional categories. They can look like harmless productivity work while still exposing regulated data, proprietary content, or secrets to a third-party model, browser extension, or tenant scope. NIST’s NIST AI 600-1 Generative AI Profile treats data handling, provenance, and monitoring as core risk areas, not optional extras. NHIMG’s research on Ultimate Guide to NHIs — Key Research and Survey Results also shows that organisations consistently struggle to see where machine identities and automation touch sensitive information.

In practice, many security teams encounter the exposure only after a downstream alert, a vendor incident, or a legal review has already exposed the workflow.

How It Works in Practice

The first step is to classify the interaction, not the employee. Determine whether the AI tool was approved, which identity authenticated the session, what data was entered, and whether the output was stored, forwarded, or reused. If the tool supports enterprise controls, check whether logging captured prompt content, model responses, file uploads, and session identifiers. If it did not, treat the session as a visibility gap.

From there, compare the workflow against the organisation’s data classification and identity policy. A prompt containing customer records, source code, contracts, or credentials may be acceptable only inside a controlled tenant with retention, DLP, and audit trails. If the employee used a personal account, a shadow AI extension, or an unvetted public chatbot, the key question is whether the prompt created an unauthorised disclosure path even if no exfiltration was intended.

• Confirm whether the AI use was covered by approved identity and access controls.
• Review logs for prompts, outputs, uploads, and any linked downstream sharing.
• Check whether sensitive data was transformed into model memory, chat history, or vendor telemetry.
• Decide whether the event requires containment, notification, policy correction, or retraining.

If the organisation already governs AI use, align the review with existing controls rather than creating a separate exception process. If it does not, use the event to define what business data may be entered, which tools are approved, and how evidence will be retained for investigations. The Microsoft Azure OpenAI service breach and DeepSeek breach show why data placement and exposure boundaries matter as much as user intent.

These controls tend to break down when employees use unsanctioned AI tools on unmanaged endpoints because the organisation cannot reliably see the prompt, the session identity, or the resulting data flow.

Common Variations and Edge Cases

Tighter AI controls often increase friction for employees, requiring organisations to balance speed against evidentiary confidence and data minimisation. That tradeoff becomes most visible in environments where business users need fast drafting or summarisation but the data involved is confidential, regulated, or contractually restricted.

Best practice is evolving for cases where the prompt includes partial redactions, synthetic examples, or publicly available data mixed with sensitive internal context. There is no universal standard for this yet. Some teams treat any prompt containing internal business content as reportable; others only escalate when the data is regulated or the tool is not enterprise-managed. The practical difference is whether the organisation can prove the boundary was controlled.

Edge cases also include employee use of sanctioned copilots that still route data through shared history, browser plugins that expand the disclosure surface, and AI features embedded in SaaS platforms where the user may not realise a model is involved. In those cases, the review should ask whether the workflow created new persistence, new third-party exposure, or new retrieval paths that were not covered by original access decisions. The real operational failure is usually not the model itself, but the absence of clear rules for what business data can be entered, stored, or reconstituted later.

Security and legal teams should treat the incident as both a privacy question and an identity question, because the control failure often starts when a legitimate employee session crosses into an unmanaged AI boundary.

Related resources from NHI Mgmt Group

• How should organisations govern data for AI when business context lives in one system and technical metadata lives in another?
• Who is accountable when shadow AI uses corporate credentials to process sensitive data?
• What do organisations get wrong about data governance for AI?
• What should organisations prioritise after identifying sensitive data?