AI Governance for Business: How to Write an Acceptable Use Policy and Get Shadow AI Under Control

Your employees are already using AI, whether you have approved it or not. A sales rep pastes a quote into a free chatbot, an analyst uploads a spreadsheet of customer records for a quick summary, a developer drops proprietary code into a public assistant. Banning AI does not stop any of this; it just makes it invisible. This guide shows how to build AI governance that fits the size of your company: an acceptable use policy people actually follow, clear data classification and an inventory of AI use cases ranked by risk.

This article is technical and informational, not legal advice. Confirm your specific obligations with qualified counsel.

What is AI governance?

AI governance is the set of rules, roles and controls that defines which AI tools an organization may use, with which data, for what purposes and under what human oversight. It is how a company gets real value from AI without exposing customer data, trade secrets or high-stakes decisions to mistakes nobody checked.

For a small or mid-sized company it comes down to five pieces: a short acceptable use policy, a data classification scheme, a list of approved tools, a use case inventory ranked by risk and human review rules.

What is shadow AI, and why should you tackle it first?

Shadow AI is employees using AI tools without the company's approval or visibility, usually through free personal accounts. It is the latest form of shadow IT, and it has three direct consequences:

• Data leakage: whatever goes into a chatbot leaves your systems and, depending on the plan, the vendor may retain it or use it to improve its models.
• Unknowing non-compliance: if it includes personal information, PHI or data covered by state privacy laws, you are sharing regulated data with a third party with no agreement in place.
• Untraceable errors: a fabricated answer ends up in a proposal or a customer email, and nobody knows it came from an AI.

What works is not blocking but providing an approved alternative that is just as convenient. Without one, people will keep using personal accounts on their phones. The practical order is: enable a safe option, publish clear rules, and only then restrict what falls outside them.

Data classification: what can go into an AI tool?

The most useful part of the whole policy is a table any employee can check in ten seconds. If you already have an information classification scheme (for example, from an ISO 27001 project), reuse it. If not, this is a reasonable starting point:

Two companion rules prevent most incidents: never paste passwords, tokens or API keys into any AI tool, and de-identify before you paste whenever the task can be done without names, Social Security numbers or account numbers.

Approved tools: what to check before you sign off

Enterprise plans typically handle your data under different terms than free accounts of the same product. Before approving a tool, check:

• Training on your data: the contract or admin settings should exclude your data from model training.
• Retention: how long the vendor keeps conversations and files, and whether you can delete them.
• Corporate identity: single sign-on with company accounts, with central provisioning and deprovisioning when people leave.
• Data location and terms: where data is processed, a data processing agreement and, before any PHI is involved, a business associate agreement.
• Admin controls: audit logs, permission management and the ability to switch off features such as connectors to email or shared drives.
• Integrations and agents: once a tool can read your inbox and documents or take actions, the risk profile changes. Our guide to prompt injection in AI agents explains why.

Use case inventory and risk tiers

Governance gets manageable once you record each concrete use: what it does, which data it touches, who owns it and what happens when it is wrong. Then you can assign a risk tier and proportionate controls:

A shared spreadsheet with use case, department, tool, data type, risk tier, owner and next review date is enough to start. High-tier cases, such as AI agents that take actions on your systems, deserve a formal review before they reach production.

Who decides? Roles and responsibilities

• Executive sponsor: approves the policy and makes the call on the highest-risk cases.
• AI lead: maintains the inventory, evaluates new tools and use cases, and keeps the policy current. In a smaller company this can be one person backed by IT and legal.
• Security and IT: set up company accounts, permissions, logging and blocking, and handle incidents.
• Legal and privacy: confirm the legal basis for processing, review vendor contracts and cross-border data flows.
• Use case owners: are accountable for output quality and human review; every employee, for using only approved tools and reporting incidents.

Human review: when is it mandatory?

AI produces convincing text that can be wrong. Your policy should spell out what cannot leave the company without a person checking it:

• Anything sent to customers, suppliers or regulators.
• Figures, calculations and data used for decisions.
• Contracts, clauses and anything with legal effect.
• Code merged into production systems.
• Any decision that affects a person: hiring, performance reviews, credit, discipline.

Review has to be real: the reviewer needs the time, expertise and authority to reject the output. For assistants serving many users, it is complemented by systematic testing, covered in our guide to evaluating AI assistants.

Reference frameworks: NIST AI RMF, ISO/IEC 42001, the EU AI Act and privacy law

You do not have to invent governance from scratch. These frameworks complement each other:

NIST AI RMF

The AI Risk Management Framework organizes risk work into four functions: Govern (policies, roles and culture), Map (context and risks for each system), Measure (testing and metrics) and Manage (prioritizing and treating risks). In 2024 NIST added a Generative AI Profile (NIST AI 600-1) covering risks such as confabulation and data privacy. For a growing company, it works as a well-ordered checklist that customers and auditors already recognize. For the technical security side, see our breakdown of the OWASP Top 10 for LLM applications.

ISO/IEC 42001

This is the first international standard for an AI management system: it defines how an organization sets AI policies, assesses the risks and impacts of its AI systems and improves over time. It shares the high-level structure of ISO 27001, so much of an existing security management system (scope, policies, internal audit) carries over. Certification is not required for good governance, but it can set you apart in enterprise sales.

The EU AI Act

The EU's AI regulation entered into force on August 1, 2024 and applies in phases. It sorts systems by risk: unacceptable (banned practices such as social scoring), high-risk (for example, systems used in hiring, creditworthiness assessment or access to education), limited risk with transparency duties (such as telling people they are talking to a chatbot or labeling synthetic content) and minimal risk. The bans and the AI literacy obligation have applied since February 2025, and the rules for general-purpose AI models since August 2025. The European Commission has proposed adjustments to the timeline for several high-risk obligations, so confirm the current dates before planning around them. For a US company, the key point is that it can reach you without any EU presence if you offer the system in the EU or its output is used there.

US and Latin American privacy rules

In the US there is no single federal AI law, but existing rules already apply to AI use: HIPAA for health data, state comprehensive privacy laws, and specific rules on automated decisions, such as New York City's bias audit requirement for automated employment decision tools. Several states have passed or proposed broader AI laws, and timelines have shifted, so track the ones that apply where you operate. If your company processes data about people in Ecuador, for example through a Latin American subsidiary or customers there, Ecuador's data protection law (LOPDP) also applies, including a right not to be subject to decisions based solely on automated processing. We cover it in AI and data protection under the LOPDP and in our LOPDP technical compliance guide.

Template: what an AI acceptable use policy should contain

A good policy fits in three to five pages. This is the structure we recommend:

1. Purpose and scope: who it covers and which tools, including AI features embedded in other software.
2. Approved tools: the current list and how to request a new one. For vendor comparisons, see choosing an LLM: Claude, GPT or open source.
3. Data classification: the table of what information may go into each tool.
4. Permitted uses: concrete examples by department.
5. Prohibited uses: pasting credentials or restricted data, using personal accounts for work, automated decisions about people, deceptive content or impersonation.
6. Human review and disclosure: which outputs need review and when customers are told AI was involved.
7. Intellectual property: checking that generated content does not reproduce protected material, plus rules for AI-generated code.
8. New use cases: how they are submitted, who reviews them and the expected turnaround.
9. Security and incidents: how to report data shared by mistake or a harmful output. Include voice and video impersonation fraud, which we cover in AI phishing and deepfakes.
10. Training: onboarding plus periodic refreshers.
11. Ownership, enforcement and review: who maintains the policy, consequences for violations and how often it is updated (at least once a year).

Rollout checklist

• Find out, through an anonymous survey or short team interviews, which tools are in use today and for what.
• Roll out at least one approved, enterprise-grade tool with company accounts.
• Publish the policy and the data classification table, and train with real examples from each department.
• Build the use case inventory with a risk tier and owner for each entry.
• Review AI vendor terms and add AI uses to your vendor and data inventories.
• Set up an incident reporting channel, SSO and logging, and schedule the first policy review.

Once you start building your own assistants, for example to query company data in plain English, the same principles carry into the technical design: least privilege, human review and evaluation before production.

Frequently asked questions

What should an AI acceptable use policy include?

At minimum: scope, approved tools, a data classification table that states what information may go into each tool, permitted and prohibited uses with examples, human review rules, how to submit new use cases, how to report incidents, training requirements and who owns the policy. Ideally it fits in a few pages and lets any employee answer common questions in seconds.

Should we just ban ChatGPT and other chatbots at work?

Banning without an alternative usually makes things worse: usage moves to personal accounts and phones, with zero visibility. It is more effective to provide an approved, enterprise-grade tool with appropriate data terms, publish which information can be used and when, and restrict only what falls outside that sanctioned option.

Does the EU AI Act apply to US companies?

It can. The regulation covers providers that place AI systems on the EU market and providers and deployers outside the EU when the system's output is used in the EU. If you sell AI-enabled software or services to European customers, check which risk category your system falls into. If you operate only in the US, focus on federal sector rules, state laws and the NIST AI RMF as your reference framework.

Do we need ISO/IEC 42001 certification?

It is not mandatory. ISO/IEC 42001 is a voluntary, certifiable standard for AI management systems. It makes sense when customers, especially large enterprises, ask for formal evidence of how you manage AI, or when you already hold ISO 27001 and want to extend your management system. For most growing companies, a policy, an inventory and baseline controls are the right first step.

How is the NIST AI RMF different from ISO/IEC 42001?

The NIST AI RMF is a voluntary risk management framework with guidance and suggested actions, and there is no certification against it. ISO/IEC 42001 is a management system standard with formal requirements that an accredited body can certify. Many organizations use both: the NIST framework and its Generative AI Profile to identify and treat risks, and ISO/IEC 42001 to run and evidence the overall management system.

Conclusion

AI governance does not slow adoption down; it makes adoption sustainable. A growing company can start with a short policy, a data classification table, one approved enterprise tool and a use case inventory ranked by risk. Frameworks like the NIST AI RMF and ISO/IEC 42001 help structure the work, while privacy laws and, for companies selling into Europe, the EU AI Act set concrete obligations. Start simple and revisit it often.

If you want to roll out AI with clear guardrails from day one, explore our AI development services or book a free consultation and we will review your use cases and risks together. Our team works from Quito in UTC-5, which overlaps the US business day.

Sources and references

• NIST: AI Risk Management Framework (AI RMF 1.0)
• NIST AI 600-1: Generative AI Profile
• ISO/IEC 42001:2023: AI management systems
• Regulation (EU) 2024/1689 (AI Act)
• European Commission: AI regulatory framework
• OWASP Top 10 for LLM Applications