Every foundation I talk to wants the same thing: staff using AI on real work, including work that touches grantee information. And most of them are closer than they think. Some have organizational licenses and connectors planned for Box, Outlook and Salesforce. Some even have outside counsel reviewing the privacy and grant-agreement questions.

What they usually don’t have is the thing that ties it all together. A license is not a policy. A connector is not a control. And a legal memo, however good, doesn’t tell a program officer at 4:45 on a Friday whether she can paste a grantee’s budget narrative into a chat window.

That gap creates real risk: staff have access to powerful tools without clear rules for using them.

The question I hear most often is a reasonable one: will technical controls take care of this? The honest answer is that they help. But no single product covers it, because different risks call for different safeguards.

Five risks and their safeguards

When we break it down with clients, the same five risks come up repeatedly. Each one calls for a different safeguard.

Two of these deserve a second look. The permissions problem is easy to overlook. AI can make existing oversharing much easier to discover. That folder someone shared with the whole organization in 2019 may now surface in an AI response.

Prompt injection is the other. It happens when malicious instructions hidden in an email, document or webpage try to redirect the AI. If a tool can read sensitive data, process untrusted content and send information out, an attacker may exploit that combination. Limiting data access and outbound actions can reduce the risk, but layered safeguards are still needed.

What a practical framework looks like

A good AI security framework is a short set of documented decisions that both people and systems can follow, reviewed as tools and uses change.

1. Know what you have. Inventory every AI tool in use, who licensed it and under what terms. You may find tools you didn’t know about. Consolidating onto approved organizational agreements makes vendor terms easier to review and enforce.
2. Classify the data. Sort grantee information into tiers (public, internal, confidential, restricted) and decide which approved tools may touch each. Then boil it down to a one-page green/yellow/red guide. If staff need to read a policy to answer a simple question, they won’t.
3. Write the policy with your lawyers, not instead of them. Privacy obligations and grant-agreement terms should shape the data tiers. Your IT partner should coordinate with counsel, not freelance legal opinions.
4. Fix permissions before you connect. Review sharing in Box, Microsoft 365 and Salesforce, find what’s over-shared and correct it. This step is the least glamorous and the most important.
5. Configure the controls. Turn on available audit logging, set retention, restrict which connectors are allowed, and use controls on managed browsers and devices to monitor AI use and block unapproved tools.

Notice the order. Policy and permissions come before the connector, not after the first incident.

Pilot before wider rollout

Don’t flip every connector on at once. Pick one system, connect it read-only with access limited to the data needed, and give it to a small group with a defined use case. Box may be a good candidate, depending on the use case and connector capabilities. Watch what happens for a few weeks, gather feedback, adjust, and only then recommend a wider rollout.

A pilot does something no framework document can. It shows you where your assumptions were wrong while the stakes are still low.

Training runs alongside it, and it should be short and concrete. Two sessions can be a useful starting point, built around three questions:

• What am I allowed to share, and with which tool?
• How do I check that the AI’s answer is actually right?
• What does a prompt injection attempt look like when it lands in my inbox?

Staff don’t need a lecture on large language models. They need to recognize the moment when they’re about to make a mistake.

Handling grantee data responsibly

Foundations carry a particular obligation to protect the information grantees entrust to them. That calls for care when using AI for grantee work.

The right contract terms, a permissions cleanup and a handful of targeted controls can make it reasonable to use certain grantee data in approved AI tools. Not all of it, and not in every tool. But enough to matter.

The tools are already on your desk. The framework is what lets you use them with confidence.

CGNET helps foundations and nonprofits put AI to work safely. If you’re working through these questions, we’d be glad to compare notes. Just drop me a line at g.*******@***et.com.