What’s a good AI policy for small businesses?

A figurative image of a shield, brain, and AI text hovering above a hand, representing AI policy management.

Editor's Note: This post was written by a human. ☺️

Have you heard artificial intelligence (AI) is going to destroy the cosmos by 2030?  We’re not sure about those headlines, but what we are sure about is that AI is ubiquitous and it’s not going away.  Your employees are most likely using AI tools on the job, whether you know it or not.  These facts can affect government contractors, suppliers, and vendors acutely, as we have contractual obligations to protect certain types of Federal government information, such as Federal Contract Information (FCI) and Controlled Unclassified Information (CUI).  And Department of War (DoW) contractors will be held accountable for protecting FCI and CUI under the Cybersecurity Maturity Model Certification (CMMC).  While the standards for protecting FCI and CUI do not (yet) specifically address the use of AI tools, there are general requirements to control the “flow” of FCI and CUI, no matter what tools are used.  In this post, we explore how small business federal contractors can craft and communicate an AI policy to ensure employees use AI tools in an appropriate manner.  Enjoy! 

Communicating an effective employee AI policy

Small businesses in all industries should have an employee AI policy, since tech companies are rapidly introducing AI, both general and generative, and Large Langage Models (LLM) into all products.  Shoot, even we’ve incorporated AI into our Totem™ cybersecurity compliance management tool!  Since your staff will not be able avoid AI, yet you have little to no control over how the AI technology handles your data, you need to set at least some basic usage boundaries. 

And those of us operating in regulated environments like federal government contracting MUST, for compliance purposes, have such a policy as part of a cybersecurity program to control how FCI and CUI is handled — stored, processed, and transmitted. 

The use of AI tools to handle FCI and CUI is not expressly prohibited, but there are certain considerations, including FedRAMP for cloud services.  A vital first step is as an organization to survey the software and cloud service landscape and determine an organizational risk-based AI policy.  The National Institutes of Standards and Technology (NIST) has published an AI Risk Management Framework to help your organization craft an AI policy.  We encourage you to leverage resources such as these to craft your own custom AI policy.

Then that policy needs to be communicated to all stakeholders, especially your users.  An effective AI policy that guides how employees interact with these tools should have the following attributes: 

  • Keep the AI policy concise and free of legalese.  This helps employees absorb and understand the policy.  Bulleted lists are great!
  • State upfront whether or not your organization allows the use of AI and LLM tools.
  • If your organization does allow the use of these tools:
    • precisely define the information types employees are and are not allowed to use the tools to handle: can they handle company proprietary info in them?  how about FCI? CUI?;
    • precisely define the tools that are and are not allowed to be used: which common generative tools, e.g. ChatGPT, CoPilot, Claude, can they use?  are these tools licensed by your organization for use, or can they use personal verions?;
    • precisely define how those tools are to be used: can they be used on workstations only?  in the cloud? on personal mobile devices?  Be explicit in all of this.
  • If your organization does not allow the use of these tools:
    • precisely define the types of information that are not allowed to be handled;
    • precisely define the types of tools that are not allowed;
    • precisely define the consequences for unauthorized use of these tools.
  • Whether AI / LLM tools are allowed or not, your AI policy should describe what employees are to do if they suspect a tool they are using that did not previously have AI integration now does.  For instance, Microsoft has been incorporating CoPilot into more and more aspects of its operating system and more and more of its M365 services.  Your employees should be coached to be cognizant of this “AI creep” and report when they see it.  The policy should also define to whom employees should report AI creep. 
  • The policy should define to whom and how employees should report violations of the AI policy. 
  • The policy should inform employees if they are or are not allowed to include AI-based transcription or summary tools in meetings they participate in.  (Remember, you have very little control where these transcriptions are handled.)  If not, instruct your staff to kick these tools out of meetings they host. 

The best way to communicate the AI policy to your staff is through a three-step process:

  1. Include the written AI policy in an Acceptable Use Policy (AUP), Rules of Behavior (RoB), or some other sort of “employee handbook”.  Ensure employees read and sign this agreement.
  2. Hold short (no longer than 1.5 hours) training sessions to cover the salient or trickiest portions of the policy.  These trainings should preferably be live, or at least offer a mechanism through which staff can have their questions answered.  
  3. Follow up with annual training refresher sessions to reiterate the important points of the policy and/or go over the changes to the policy. 

If your organization doesn’t yet have an AUP, we offer a template that includes an starter AI policy for download as part of the library of policy and procedure resources in our Totem™ tool.  If you’re interested you can sign up for a free trial on this page. 

Policies to include if you're building tools with AI integration

To ensure control over their data but still enjoy the productivity benefits that AI tools offer, more and more companies are integrating organizationally-controlled AI and LLM into their own tools.  This practice is not prohibited for those of us handling FCI and CUI, but there are some considerations, including FIPS validated cryptography. 

The aforementioned NIST AI Risk Management Framework has some high-level guidance on managing the risk of such integrations, but we figured as a real-world example we’d share our general approach for a policy controlling AI integration in our own tool: the Totem™ cybersecurity compliance management tool.  Starting in Totem™ version 6.0, we integrated an LLM chatbot we affectionally named “Aurora”. 

Aurora can help with basic cybersecurity compliance management tasks within the tool, including summarizing compliance implementation and performing security impact analyses.  But we recognized the risk of AI integration into our cloud-based tool, so we put some “guardrails” around Aurora to assure the sovereignty, confidentiality, and integrity of our clients’ data in the tool.  We detail these guardrails in our Security Features page, but we’ll outline the general AI policy principles here:

  • Define and enforce a “scope” for the AI or LLM code integration.  For Aurora, each Totem™ instance runs a separate LLM, and there is no central “Aurora server”.  This helps segregate user data and ensure the LLM cannot “leak” data between servers.
  • Define and enforce the usage scope.  We’ve erected logical barriers to ensure any given user can only engage Aurora with their own organization’s data. Coding barriers restrict the types of prompts, tasks, and data entry the users can attempt to engage with Aurora. Again, this is designed to prevent unintentional data “leaking” through Aurora.
  • Tightly control the data the AI tool is trained on.  Aurora is only trained on resources we explicitly provide to it, and only when we explictly provide those resources through specialized training mechanisms.  Logical firewalls and cloud service infrastructure ensure Aurora does not have general Internet access.  And the scoping considerations outlined above and the data retention policy outlined below ensure Aurora is NEVER trained on user data.  This policy has two-fold purpose: again to ensure against data “leakage”, but also to ensure consistency and integrity of Aurora’s responses. 
  • Enable Zero Data Retention policies.  All LLM developers (in Aurora’s case OpenAI and ChatGPT) would love to have the feedback from all the various implementations of their models to better inform improvments to the model.  But any feedback path is an opportunity for potential user data spillage.  So you’ll need to take advantage of the underlying architecture settings to ensure the LLM vendor does not get hold of any information about the use of their models, especially not user data but even meta-data about how the model is used.  For Aurora we cranked down all possible data retention settings we could using the Amazon Web Services (AWS) Bedrock infrastructure. 

Wrapping up

So there you have our take on a foundational approach to establishing and implementing AI policy for your employees and with which to guide AI and LLM integration into your organizations toolsets.  

As a reminder, if you’d like an AI policy template, we offer one for download in our Totem™ cybersecurity compliance management tool.  Start your free trial here.  

Good Hunting!

–Adam

Like this post? Share it!

Get notified when new blogs are published!