TBW / AI USE CASES
Secure Employee AI Adoption
Give employees approved AI tools and clear data-handling rules instead of leaving them to personal accounts and unmanaged services.
The Employee AI Problem
This is a design pattern, not a customer case study. The goal is to make permitted use understandable and useful, not merely issue a prohibition.
Unreviewed tools
Personal accounts and new AI services may process corporate information without an organization review.
No practical alternative
If an approved tool cannot support common tasks, a written policy alone may not change behavior.
Limited visibility
Teams may lack a view of services used, data shared and connected OAuth applications; visibility depends on available systems.
Start by interviewing users about real tasks and mapping data classes before selecting technology.
From Unmanaged to Governed Use
Unmanaged path
Employee → public AI service → corporate data outside approved controls. This illustrates exposure, not a claim that every public service is unsafe.
Governed path
Employee → approved AI entry point → identity → data policy and DLP → approved model route → appropriate audit and governance.
Tool tiers: Approved for normal defined use, Limited under task and data restrictions, and Prohibited for uses not authorized by the organization. Publish task-oriented guidance and a useful approved option so the compliant path is practical.
Architecture and Integrations
An approved portal or entry point can authenticate through SSO, apply user and data policy, and route requests through a model gateway to reviewed providers or models. Data classification and DLP/redaction can check prompts and uploads before model access. Where supported, CASB/proxy signals and OAuth application inventories add visibility; logs should record decisions without retaining unnecessary sensitive content.
Not every deployment needs every product category. Define ownership for identity, provider review, exceptions, logging, retention and user support before rollout.
Six Operational Controls
Acceptable use
Write short rules by task and data class, with an accessible exception path.
Approved tool catalog
Make approved tools searchable by the tasks employees need to perform.
Data classification
Explain what may be entered, uploaded or shared with each tool tier.
DLP and redaction
Detect or transform sensitive values where appropriate, with false-positive review.
Approved model routes
Enforce eligible destinations for each workload and data class.
Fast tool review
Give new-tool requests an owner, evidence checklist, decision and expiry/review point.
What a Team Receives
Policy and catalog
A task-oriented acceptable-use guide, approved/limited/prohibited tool catalog and review workflow.
Architecture and control map
Entry-point design, identity/model-route decisions, data-class rules and logging/retention model.
Rollout evidence
Pilot scenarios, training material, exceptions process and an evaluation/reporting plan.
The exact artifacts depend on scope and the customer’s existing systems and policies.
Success Measures
Observe approved-tool adoption, discovery of unmanaged usage, sensitive-prompt prevention, exception volume, review turnaround and employee feedback. Track false positives and blocked legitimate work as well as policy enforcement; no universal target values are assumed.
A Bounded Pilot
Start with one department, one approved assistant, one policy model and one training session. Inputs include a policy owner, representative employee tasks, data-class definitions and the reviewed service list. Test allowed, blocked and exception cases with real users; monitor whether they can actually complete their work without bypassing the approved route.
Risks and Response
| Risk | Response |
|---|---|
| Users bypass the portal | Make the approved route useful, available and easy to discover; ask why users leave it. |
| Policy nobody reads | Offer short, task-oriented examples, not a legalistic list alone. |
| Over-blocking | Test rules with representative work and provide an exception review path. |
| Local desktop AI tools omitted | Include installed/local software and its data flows in the acceptable-use model. |
Frequently Asked Questions
Why not simply block all public AI?
A blanket block may leave useful work without an approved path. Classify data and tasks, offer reviewed alternatives and restrict destinations that do not meet policy.
Can some AI tools be allowed but others limited?
Yes. Define approved, limited and prohibited tiers with owners, data rules, and a review process for changes.
How do we reduce sensitive prompts?
Combine understandable user guidance with classification and tested DLP/redaction at the entry point; review misses and false positives.
Can employees use local AI?
Possibly, if the local tool, data storage, model provenance and support model meet the organization’s policy. Local alone does not establish safety.
What belongs in an approved AI policy?
Allowed tasks and data classes, approved tools, prohibited uses, review and exception paths, reporting, ownership, and retention expectations.
Give Employees a Safer Starting Point
Bring the common employee tasks, current tool inventory and data policies to a scoped conversation.