Skip to content 
By: Shayne Champion | Published: September 9, 2026 | 
14 Min
Summary:
Most program directors underestimate the extent to which staff is already using AI at work. This article covers practical steps to close that gap, providing six simples steps that can help you catch up and get ahead of the looming AI security concerns before they become serious issues.
Ask a room full of program directors whether their staff use AI at work, and most will probably say, “a little, maybe. We haven’t really looked into it.” But if you were to privately ask the staff themselves, you’ll get a different answer. Someone’s pasting case notes into a free chatbot to tighten up the language. Someone’s using an AI transcription tool on a family visit because it’s faster than typing. Someone found a browser extension that “summarizes anything” and has been feeding it documents for months.
None of that is malicious. It’s people trying to get their jobs done in a sector that never has enough hours in the day. But if you can’t measure the scale, if you don’t have an AI security program. Instead, you have a security gap with a very human consequence.
This is the second piece in our series on AI security for human services organizations.
See our first article in this seriesOur first article covered the fundamentals of how these tools actually work. And here, we’re going to cover the part most organizations skip: actually implementing security practices, not just writing them down.
The underlying problem is that most information security professionals are intimidated by the concept of AI. And there’s a lot to understand! But the more experience you get with AI, the more you’ll realize that the concept, and therefore the right steps for security, is very similar to that of other technologies. One of those important things is that we can’t control AI with technical controls alone. At the end of the day, AI security will depend as much on the actions humans take as it does on automated tools, so we can’t lose focus on our users in this shuffle. With that being said, let’s sit back, take a deep breath, and talk about some practical things you can do within your organization to start securing it from AI, from the inside out.
Today we’re going to talk about some of the basics of a good AI security program starting with building an AI policy; moving on to discovery; then user training, access control for AI agents, keeping humans in the loop; and wrapping up with incident response.
Start by Writing a Policy People Can Actually Follow
This all starts off with a directive control: creating an AI policy. We need to let people know what is acceptable with AI use and what isn’t before we start taking more direct action. To be honest, most acceptable use policies fail for one reason: nobody who has to follow them can remember what’s actually in them. A twelve-page AI policy written in legal language is not a security control; it’s just a document that exists so someone can say it exists.
What you need is a policy that works by fitting on one page and answers three questions in plain language:
What tools are approved for use with client information, and where do people find that list?
What data can never go into an AI tool that isn't specifically approved for it: full names, case numbers, anything that could identify a client, health information, and so on.
Finally, who do you ask when you're not sure? That last one matters more than people think. If the answer to "who do I ask" is unclear, staff will guess, and they'll usually guess wrong in the direction of convenience.
There’s a lot of good direction out there on the internet to help you with your AI policy, but you have to not ignore some of the best help you can get: the folks you already work with. Write it with the people who’ll use it, not just for them. Pull in a few frontline staff and a program director before you finalize anything and get their feedback. They’ll catch the parts that sound fine in a conference room but fall apart in a real caseload.
Finding Out What’s Already Happening
Now that you’ve set some direction for your organization, we must quantify the scope of the problem you’re addressing. You cannot secure what you don’t know exists, so spend two weeks finding out what AI tools are already in use across your organization. If you don’t have any discovery tools, no problem. But don’t just send a memo asking people to self-report; have some real conversations. Sit down with a handful of frontline staff in different roles and just ask what AI tools they’ve tried, what’s helped, what have they been nervous to admit they’re using?
I promise you’ll find more than you expect. This is often called “shadow AI,” and it’s the AI-era version of shadow IT: the unsanctioned software people install because the sanctioned option is slow, clunky, or doesn’t exist. The fix isn’t to shame people for finding workarounds or ways to be more efficient, but to build something better than the workaround, and fast enough that they’ll actually switch to it.
Train the People, Not Just the Tool
Here’s a mistake many organizations make repeatedly: they roll out an AI tool, send a link to the vendor’s documentation, and consider training complete.
It isn’t. Vendor documentation teaches people how to click buttons. It doesn’t teach them what a hallucination looks like in a case note, why they still have to read every word the AI drafts before approving it, or what to do if the tool produces something that feels off.
When we rolled out AI tools internally at CaseWorthy, we didn’t stop at a policy document. We built an actual training program: a presenter walkthrough, a plain-language cheat sheet staff could keep at their desk, and short interactive exercises that got people applying the concepts instead of just reading about them. It took more effort than sending a memo.
Training has to answer a specific question for every role that touches AI: what does “good” look like when you use this tool, and what does a red flag look like? If staff can’t answer that after training, the training didn’t work, regardless of how good the slides looked.
By the way, that training mandate goes for your policy too. Once you have your policy approved, make sure that you train your staff on it as well. Having a policy without training is just as ineffective as giving your 16-year old a new car without driver’s ed. It’s also the difference between a policy that lives in a drawer and one that actually shapes behavior.
Control Your Agents
Reiterating a point from the first article, it’s critical that we understand that AI isn’t just another program. Normal programs and applications use algorithms, a defined and predictable flow of data processing and output. You know that if you put information X in one end, you’ll get result Y at the other. However, AI works on other, far more complex principles. Ultimately, AI doesn’t have algorithms, but objectives.
The problem is that we don’t (and maybe can’t) know exactly what those objectives are. This means that we must treat AI and AI agents not as programs, but as untrusted users. It’s so easy to just give an AI agent all the access it asks for in the name of progress but that’s a dangerous precedent to set. Make sure that AI access is granted based on minimum necessary and least privileged principles, just like any other user. If you have an AI agent that gets access keys, those need to be rotated regularly.
The other important thing is you need to regularly review what access your AI agents have. It’s so easy to assign privileges based on how a user is implementing that agent, but if that person moves on it’s very easy for that agent to still be there with all that access. To manage AI agents, we have to start with managing that access and make sure it’s removed when unneeded, just like you’d do with any regular user.
Granted, there are more advanced controls that you can put in place if you have the budget for it, like AI gateways. However, implementing these fundamental controls will go a long way towards establishing effective management of your AI agents.
Keep Humans in the Loop
This seems so trite, but I’ve personally seen how quickly we become confident in the speed, ease, and efficiency of AI that we take our hands off the proverbial wheel. We simply can’t do that, and it starts with that training we talked about earlier. AI hallucinations—an AI response which contains false, fabricated, or misleading information presented as absolute fact—are a real (and dangerous) thing. You cannot implicitly trust any AI without human review. And when you’re talking about data that impacts the people we’re serving, we have to make sure that there’s always a real person reviewing that output and making the final call.
The trick is you don’t need to create a brand-new oversight process that lives outside your normal operations. It’ll get skipped the first busy week. Instead, fold AI review into checks you’re already doing. If you already do periodic case file audits, add a question about AI-assisted content to that audit. If supervisors already spot-check a sample of case notes, have them note which ones involved an AI tool and whether the human review actually happened, not just whether it was supposed to.
This is the same principle we build into Cara, the AI assistant inside the CaseWorthy platform: the AI drafts and surfaces information, and a person reviews and approves before anything becomes final, with that data staying inside your own environment throughout. Whatever tool you’re using, internal or vendor-provided, that review step needs to be a real habit your team practices, not a checkbox in a policy nobody reopens after the rollout.
Treat AI Incidents Like Any Other Incident
At some point, something will go wrong: an AI tool will surface something it shouldn’t have, a staff member will paste something into the wrong window, a vendor will change how their tool handles data without much notice. Decide now, before it happens, how you’ll respond. Fold AI-related incidents into your existing incident response plan rather than building a parallel process. Who gets notified, how fast, and what gets documented should already have answers by the time you need them.
The key here should sound familiar; don’t treat AI as a program, treat it (and think about it) just like you would any other user. If you do that, you’ll find that many of your existing incident response process and playbooks still apply. Treat a near-miss (e.g. an AI draft that almost went out with a client’s identifying details in the wrong place) the same way you’d treat any other near-miss. Log it, learn from it, and adjust the process. Organizations that punish people for reporting AI mistakes will simply stop hearing about them, and the mistakes will keep happening quietly instead.
Small, Consistent Steps Beat a Perfect Plan You Never Start
If you’re waiting for the perfect AI security policy before you let any team use these tools, you’re already behind. Your staff are using them anyway, just without the guardrails you’d have chosen. Start with these six points:
- Start with the conversation about what's already happening.
- Write the one-page policy.
- Train people for real.
- Monitor and manage access for AI agents.
- Keep people in the review loop.
- Have an incident plan ready before you need it.
About the Author
Shayne Champion
Shayne Champion is the Chief Information Security Officer at CaseWorthy, a human services software company serving organizations across homelessness services, behavioral health, aging, I/DD, and more. With over 20 years in cybersecurity, he has built and led security programs at the Tennessee Valley Authority, BlueCross BlueShield of Tennessee, Erlanger Health System, and Conversant Group. He holds CISSP, CISA, and GSEC certifications and serves on the Chattanooga ISSA board of directors.
Frequently Asked Questions
What should an AI policy actually include?
Just three things, in plain language, on one page: which AI tools are approved for use with client information, what data can never go into an unapproved tool (names, case numbers, anything identifying, health information), and who to ask when staff are unsure. The article stresses writing it with frontline staff and program directors, not just for them.
Is vendor training enough once we roll out an AI tool?
No. Vendor documentation teaches people which buttons to click, not what a hallucination looks like in a case note, why every AI draft still needs a human read-through before approval, or what to do when something feels off. Real training has to teach staff what “good” and “red flag” look like for their specific role.
How should we manage access for AI agents?
Treat AI agents like any other user, not like a standard piece of software. That means granting access on a least-privilege, minimum-necessary basis, rotating any access keys regularly, and reviewing agent access periodically so it doesn’t linger after the person who set it up moves on.
Why does human review still matter if the AI tool is reliable?
Because AI can hallucinate, presenting false or fabricated information as fact, and that risk is unacceptable when the data affects the people an organization serves. Rather than building a separate oversight process, the article recommends folding AI review into audits and spot-checks organizations already do. This is the same principle behind Cara, the AI assistant inside the CaseWorthy platform: it drafts and surfaces information, but a person reviews and approves before anything becomes final, with data staying inside the organization’s own environment throughout.
