AI Lockdown and Security: Locking Down Corporate AI Usage

AI Lockdown and Security: Locking Down Corporate AI Usage Webinar Summary
Based on the related webinar presented live on October 7, 2026, by Jason Nadal, Information Security Officer, Besler Holdings / Sypher Security, and Ramey Burke, Director of Software Development, Besler Holdings / Sypher Security as part of The Hospital Finance Academy.
The Reality: AI is Already in the Building
Someone on your team is using AI today. Ideally, that use runs through an approved path. In practice, it often does not.
Industry research makes the gap hard to ignore:
- IBM’s Cost of a Data Breach Report 2025 found that 63% of breached organizations had no AI governance policy or were still developing one. Only 34% of organizations that did have a policy regularly audited for unsanctioned AI. (IBM)
- Gartner research, based on a survey of cybersecurity leaders, found that 69% of organizations already suspect or have evidence that employees use prohibited public generative AI tools, and predicts that by 2030 more than 40% of enterprises will experience a security or compliance incident tied to unauthorized shadow AI. (Gartner)
- Netskope has reported that the average organization logs on the order of 223 generative AI data-policy violations per month. (Netskope)
For hospital finance and revenue cycle teams, the stakes aren’t abstract. A wrong note pasted into a public chatbot can put protected health information (PHI) or confidential financial data outside your control. A helpful summarizer can invent clinical or financial “facts.” An automation that writes back into a system can turn a bad model answer into a real patient or operations problem. And “just this once” pastes—customer lists, forecasts, source code, API keys, contracts—are how most incidents start.
The governing question from the webinar is the right one:
Do we know what we allow, what we forbid, and how we keep that promise when products keep shifting underfoot?
Where AI Earns Its Keep—And Where It Doesn’t
Corporate AI is worth governing because it’s worth using. Done inside clear boundaries, it shortens work that used to waste time.
| Use | Legitimate Value | Non-negotiable Condition |
| Drafting and summarizing | Faster first drafts of notes, memos, and analyses. | Data class matches the tool’s approval. |
| Search and triage | Faster pattern-finding across tickets, notes, and prior-authorization paperwork. | Retrieved content stays inside policy. |
| Coding assists | Faster first drafts when the use case matches the risk. | Human owner, review, and least privilege. |
| Human oversight | Real gains only when people remain accountable for the output. | No unsupervised write-back on high-impact actions. |
Treat AI like a system, not a clever notepad. It can see data (prompts, uploads, retrieved content, and memory) and take action (write-backs, agents, APIs, email, tickets, schedules). It deserves the same honesty you apply to any system with reach.
AI can be a productive contributor, but it cannot be an accountable engineer.
A Methodology of Control You Can Actually Run
The webinar’s core framework is a five-prong approach. Skip any one of them and the others leak.
1. Write an AI Usage Statement
No written position means every employee invents their own. That’s unmanaged risk.
A usable statement is plain language, not a legal appendix. It should cover:
- What is allowed versus not allowed.
- Who may use which class of AI.
- Which data classes never leave the building.
- When a human must stay in the loop.
- A default rule: unsure? Ask before you paste.
- A lifecycle: publish it, train on it, refresh it.
2. Assess the Specific AI—Not “AI” in General
“Is this tool good for our purpose?” is a vendor and architecture question. Ask it every time:
- Where do models run? On your side, theirs, or both?
- Retention and training. Are prompts and outputs kept, or used to train?
- Sub-processors. Who else touches the data path?
- Write-back risk. Can “AI features” change your systems?
- Trust history. Past leaks, rule-skirting, or scraping?
- Zero-retention claims. Verify “ZDR” or no-collection language. Don’t accept the marketing line at face value.
- Does this model and/or AI architecture fit my needs? Ensure that you’re limiting usage to approved data and that only what is needed for that context is approved.
3. Draw Systems-Access Boundaries: Private, Public, and Internal
| Boundary | What It Is | How to Govern It |
| Private | AI hosted inside company boundaries—your model, your network. | Still govern who, what data, and logging. Private is not the same as unsupervised. |
| Public | Third-party AI on the open internet. | Decide who can get there and keep policy current. Blind open access is worse than a controlled path. |
| Internal | AI baked into platforms you already approved. | Treat it as change management, not “already approved forever.” Feature flags count. |
4. Classify Data by Impact, Then Set the Path
Ask out loud: If this type of data were released, what would the impact be to our company and its reputation?
| Class | Rule of Thumb |
| Public | OK to share broadly. |
| Internal | Staff use; not for public prompts. |
| Confidential | High impact if leaked. |
| Regulated | PHI and similar—strictest path only. |
Other tooling—DLP, gateways, logging—only works if it sits on top of knowing what data you have and where it lives. Classification is the foundation, not a spreadsheet exercise.
5. Prevent Misuse, Including by Agents
People and attackers will try to steer agents off-policy. Design for that:
- Override attempts. Expect hostile prompts.
- Least privilege. Agents should touch only what they must.
- Human confirmation. High-impact actions need a person in the loop.
- Monitor and revoke. Watch privileged automations and cut access fast when something is wrong.
Assume subversion. There’s no free rein.
Tooling Categories That Enforce the Promise
Policy without enforcement is a poster. The webinar groups practical controls into five categories:
- AI filters / firewalls — inspect prompts and responses for policy and sensitive patterns.
- DLP for prompts — catch risky pastes and file uploads to AI tools.
- Gateway controls — allow, block, or broker access to public AI destinations.
- Logging and monitoring — who used what, when, and with what sensitivity signals.
- Identity / SSO gating — private AI still needs authentication, with the same hygiene as other systems.
Blocking alone is a weak strategy. Research summaries of employee behavior consistently show that a large share of staff work around blocked apps when no approved alternative exists. Pair restrictions with a sanctioned path, or shadow use fills the gap.
Feature Creep: Last Year’s Approval is Incomplete
Last year’s CRM had no generative sidebar. This year’s update does. Your old approval letter doesn’t cover it.
- Spot it. Train users to notice new AI features in tools they already use.
- Re-open the assessment whenever an approved vendor ships AI.
- Don’t wait for an incident. Discover the new button before something goes wrong.
Internal AI is change management. “Already approved” is not a permanent state.
AI In Your Own Software, Vendors & Open Source
If you build or buy software that uses models, the same methodology extends into the software development lifecycle and the supply chain.
In-house development
- Every AI-generated change needs a human owner who can explain it. If nobody understands it, it’s not ready to merge.
- Requirements, peer review, tests, scanning, and release approvals still apply. AI doesn’t skip the SDLC.
- Coding assistants shouldn’t see every repository, secret, or production credential. Log access. Require humans for consequential actions.
- Models may suggest plausible package names. Verify publisher, source, license, and vulnerabilities before you pin them.
- Treat documents, web pages, email, and other retrieved material as untrusted data. Input filtering alone cannot make natural language instructions trustworthy, and an AI firewall cannot determine whether every instruction is safe.
Vendors and SaaS
- Is AI in the data path?
- Where does data go?
- Who are the sub-processors?
- What happens if the model provider changes terms?
- Put AI questions in every questionnaire.
Open-source libraries
- Model SDKs, vector libraries, and agent frameworks can make unexpected outbound calls and send telemetry.
- Inventory them, pin versions, and watch advisories.
- Verify the publisher before adding a package.
- Don’t let an SDK become a side door.
Stay ahead: Inventory, Constrain, Test
AI risk is not a one-time vendor check.
| Motion | What “Done” Looks Like |
| Inventory and classify | You know which AI products and features exist, what data they can access, and who owns each use case. |
| Constrain and observe | Permissions, autonomy, retention, and cost are limited. Activity is logged. Abnormal behavior is detectable. |
| Test and own | Expected and hostile scenarios are exercised. A human is accountable for each consequential outcome. |
9 Takeaways for the Leadership Conversation
Talk about what you have, how it’s used, and how you manage risk—before an incident forces the conversation. Bring three questions into the room:
- Inventory. Where is AI in our environment today?
- Risk appetite. What data are we willing to risk if it leaked?
- Playbook. Does our incident response cover AI misuse?
Then assign owners to these 9 actions:
- Write the AI Usage Statement—allowed, forbidden, ask first.
- Assess AI wherever it shows up—new, old, and feature flags.
- Separate Private, Public, and Internal, and govern Internal as change.
- Classify data with an impact question.
- Constrain agents—assume subversion; no free rein.
- Use tooling categories to enforce and observe.
- Revisit approved tools when AI appears.
- Extend vendor and open-source review to AI dependencies.
- Have control over your software development, or at least insight into your third-party’s software development landscape to make sure they have the same types of guard rails and risk tolerance that you recommend.
Leadership should approve data risk tolerance.
Next Steps
- This week: Name an owner and draft a one-page AI Usage Statement (allowed, forbidden, data classes that never leave, human-in-the-loop rules, “ask before you paste”).
- This month: Inventory AI already in use—public tools, private deployments, and AI features inside approved platforms—and map each to a data class.
- This quarter: Add AI questions to vendor questionnaires, re-open assessments where feature creep has already landed, and confirm incident response covers AI misuse, including agent write-back.
- Ongoing: Publish, train, and refresh. Tools will keep shifting. The promise has to move with them.
Accountability extends beyond developers–AI-assisted presentations, analyses, and client-facing work also require human oversight.
Hospital finance, revenue cycle, and compliance leaders don’t need a ban. They need a methodology they can run: a written position, an assessment habit, clear boundaries, classified data, and controls that assume misuse.
If you want to pressure-test that program—tabletop drills, a unified view of vulnerabilities and third-party risk, or a leadership briefing grounded in this framework—connect with the Besler Holdings / Sypher Security team.
Watch the related Webinar: AI Lockdown and Security: Locking Down Corporate AI Usage to learn more.



