Lock In Compliance: Your AI Safeguard System

Most organizations using AI tools today have no formal compliance program. They have a few enthusiastic employees, a handful of approved tools, and a vague policy that nobody reads. That gap is closing fast, regulators, clients, and boards are starting to ask hard questions. This lesson shows you how to build a real AI compliance program from scratch, even if you have no legal or technical background. You will leave with a framework you can adapt to your organization's size, industry, and risk level.

7 Things to Know Before You Start

1. An AI compliance program is not a one-time policy document, it is an ongoing system of controls, reviews, and accountability structures that evolves as your tools and regulations change.
2. You do not need a legal team or a data scientist to start. A compliance program begins with a clear owner, a documented inventory of AI tools in use, and a basic risk assessment.
3. The EU AI Act (fully enforced from August 2026) classifies AI systems by risk level, unacceptable, high, limited, and minimal. Knowing where your tools land determines how much governance you need.
4. The biggest compliance risks for non-technical professionals are data privacy violations (sharing personal data with AI tools), output accuracy failures (acting on hallucinated AI content), and vendor lock-in without contractual protections.
5. A compliance program has five core pillars: Governance, Inventory, Risk Assessment, Controls, and Monitoring. Every section of this lesson maps to one of these pillars.
6. Microsoft Copilot, Google Gemini Workspace, and Salesforce Einstein all have enterprise data processing agreements (DPAs) available. Free-tier tools like ChatGPT (non-Plus) may not offer the same contractual protections, a critical distinction for regulated industries.
7. Internal AI policies fail when they are built top-down with no employee input. The most effective programs include frontline staff in identifying how AI is actually being used before any rules are written.

Click to enlarge

Pillar 1: Governance. Who Owns AI Compliance?

Governance means deciding who is responsible for AI decisions in your organization. Without a named owner, compliance tasks fall through the cracks. In large organizations, this is often a Chief AI Officer, Chief Risk Officer, or a cross-functional AI Steering Committee. In small and mid-size businesses, it is typically the operations manager, IT lead, or a senior manager who champions the effort. The role does not require technical expertise, it requires authority to approve or block tools, access to legal and HR resources, and accountability to leadership for AI-related incidents.

Governance also means defining your decision-making process before problems arise. Who approves a new AI tool before it is used on client data? Who decides if an AI-generated report needs human review before being sent externally? Who gets notified if an employee accidentally pastes confidential client data into a free AI chatbot? These questions need written answers. A one-page AI Decision Matrix, mapping tool categories to approval requirements, is often enough to start. You do not need a legal department to create one; you need clear thinking about your organization's biggest risks.

• Assign a named AI Compliance Owner, one person who is accountable, not a committee that shares responsibility without individual accountability.
• Create an AI Steering Group with representatives from Legal/Compliance, HR, IT, and at least one business unit manager who uses AI tools daily.
• Define three tiers of AI tool approval: Self-service (no approval needed, e.g., Grammarly), Manager-approved (e.g., using ChatGPT Plus for client-facing content), and Compliance-reviewed (e.g., AI tools processing HR or financial data).
• Document your escalation path: who an employee contacts if they suspect an AI tool produced a harmful or inaccurate output.
• Set a governance review cadence, quarterly for fast-moving environments, semi-annually for stable ones, to revisit approved tools and policies.
• Ensure your AI Compliance Owner has a direct reporting line to the CEO, Board, or equivalent senior leadership so decisions have organizational weight.

Click to enlarge

Pillar 2: Inventory. What AI Are You Actually Using?

You cannot manage what you have not counted. An AI tool inventory is a living document that lists every AI-powered tool in use across your organization, approved or not. This is harder than it sounds. Most organizations discover during their first inventory that employees are using 8 to 15 AI tools that IT and leadership did not know about. This is called shadow AI, and it is the compliance equivalent of shadow IT from the 2010s. Common shadow AI tools include personal ChatGPT accounts, Notion AI on free plans, AI-powered browser extensions, and consumer-grade transcription tools used on client calls.

Building your inventory starts with a staff survey, not an IT audit. Ask employees directly: 'What AI tools do you use to do your job, including free personal accounts?' You will get more honest answers than from a software license review alone. Once you have a list, categorize each tool by data sensitivity, vendor, cost, and whether a formal contract or data processing agreement exists. The goal is not to ban everything, it is to know what you have so you can make informed decisions about what stays, what gets upgraded to an enterprise plan, and what gets removed.

1. Send a short anonymous survey to all staff asking which AI tools they use weekly, including free personal accounts and browser extensions.
2. Compile responses into a single spreadsheet with columns for: Tool Name, Vendor, Plan Type (Free/Paid/Enterprise), Primary Use Case, Data Sensitivity, and Current Approval Status.
3. Flag any tool that touches personal data (employee info, customer data, financial records) for immediate compliance review.
4. Check whether each flagged tool has a signed Data Processing Agreement (DPA), most enterprise plans (Microsoft 365 Copilot, Google Workspace with Gemini, Salesforce Einstein) include these; most free plans do not.
5. Assign each tool a status: Approved, Conditional (approved with restrictions), Under Review, or Prohibited.
6. Publish the approved tool list internally so employees know what they can use without asking for permission every time.
7. Schedule a quarterly review to add new tools and re-evaluate existing ones as vendor policies and your organization's needs change.

Pillar 3: Risk Assessment. Ranking Your Exposure

A risk assessment is how you decide where to spend your compliance energy. Not every AI use case carries the same risk. Using ChatGPT to draft a social media caption is low risk. Using an AI tool to screen job applications is high risk, it touches employment law, potential bias, and in some jurisdictions (New York City Local Law 144, for example) requires an annual third-party bias audit. A practical risk assessment for non-technical professionals does not require a consultant or a risk management software platform. It requires honest answers to four questions about each AI use case in your organization.

The four questions are: (1) What data does this tool process, is it public information, internal business data, or sensitive personal data? (2) Who is affected by the AI output, internal staff only, or external clients and customers? (3) What happens if the AI output is wrong, minor inconvenience or serious harm (financial loss, discrimination, safety risk)? (4) Is there a human reviewing the output before action is taken, or does the AI output trigger an automatic decision? The answers map directly to a risk tier. Low, Medium, or High, which then determines what controls you need to put in place.

Click to enlarge

Part 1 Cheat Sheet

• A compliance program has five pillars: Governance, Inventory, Risk Assessment, Controls, and Monitoring.
• Governance starts with one named owner, not a committee, who has authority and accountability.
• Shadow AI is real: staff surveys reveal 8–15 unapproved AI tools in most organizations.
• Free-tier AI tools (ChatGPT free, Notion AI free, Otter.ai free) often lack DPAs, a critical gap for client or personal data.
• Enterprise plans with DPAs: Microsoft Copilot (M365 Enterprise), Google Gemini (Workspace Business), ChatGPT Enterprise, Claude Enterprise, Grammarly Business, Notion Business.
• Risk tiers: Low (internal, non-sensitive, reversible errors) / Medium (business data, external visibility) / High (personal data, automated decisions, legal liability).
• High-risk AI use cases in hiring, credit, and healthcare carry specific legal obligations. NYC Local Law 144, EU AI Act, HIPAA.
• Your first three deliverables: AI Inventory spreadsheet, DPA gap list, one-paragraph Governance Statement.
• Approval tiers simplify day-to-day decisions: Self-service (Grammarly-style) / Manager-approved (client-facing AI) / Compliance-reviewed (HR, financial, health data).
• Risk assessment asks four questions: What data? Who is affected? What if the output is wrong? Is a human reviewing before action?

Key Takeaways from Part 1

• Most organizations have no formal AI compliance program, and most are already exposed to risk through unapproved tool use.
• Compliance governance requires a named owner with real authority, not a working group with shared responsibility and no accountability.
• An accurate AI inventory is impossible without asking employees directly, software audits alone miss consumer and free-tier tools.
• Risk tier classification is the bridge between your tool inventory and the controls you need, skip it and you will either over-regulate low-risk tools or miss serious exposure in high-risk ones.
• Part 2 will cover Pillar 4 (Controls) and Pillar 5 (Monitoring), the operational systems that make your compliance program functional day to day.

Part 1 established why AI compliance matters and what a program needs to cover at a high level. Now comes the operational work, the policies, roles, risk registers, and vendor checks that turn good intentions into a functioning compliance program. This section is designed as a working reference. Return to it when you're drafting policy, onboarding a new AI tool, or preparing for a compliance review.

7 Things Every AI Compliance Program Must Address

1. A written AI Use Policy that names approved tools, prohibited uses, and data handling rules, not a vague 'use AI responsibly' statement.
2. A designated AI compliance owner, one person or team accountable for policy enforcement, not a committee that diffuses responsibility.
3. A vendor review process that checks every AI tool before employees use it with real company or client data.
4. A risk register that catalogs each AI use case, its risk level, and the controls in place, reviewed at least quarterly.
5. Employee training that is role-specific: what a salesperson needs to know differs from what HR needs to know.
6. An incident response plan for AI-specific failures: biased outputs, data leaks through AI tools, hallucinated content sent to clients.
7. Audit and documentation trails so you can demonstrate compliance to regulators, clients, or leadership on demand.

Writing a Policy That People Actually Follow

Most AI policies fail because they are written for lawyers, not employees. A policy that says 'personnel shall exercise appropriate judgment regarding artificial intelligence outputs' tells nobody what to do on a Tuesday afternoon. Effective AI Use Policies are specific enough to answer real questions: Can I paste client data into ChatGPT? Can I use Copilot to draft a performance review? Can I share a vendor contract with an AI summarizer? If your policy doesn't answer those questions, employees will make their own decisions, and some of those decisions will create liability.

A strong AI Use Policy has three tiers: approved tools (green list), tools requiring case-by-case approval (amber list), and prohibited tools or uses (red list). Each tier needs a brief rationale so employees understand the logic, not just the rule. The green list should specify data restrictions, for example, ChatGPT Plus may be used for drafting external communications but not for processing personally identifiable information. Revisit the policy every six months. AI tools update constantly, and a policy written in January can be outdated by June.

• Green list: Approved tools with defined data restrictions (e.g., Grammarly AI for editing, Canva AI for marketing graphics, Microsoft Copilot within your Microsoft 365 tenant).
• Amber list: Tools requiring manager or IT sign-off before use with sensitive data (e.g., new AI meeting transcription tools, AI contract reviewers from unknown vendors).
• Red list: Prohibited uses regardless of tool, entering client financial data, patient records, employee salary data, or trade secrets into any public-facing AI model.
• Version control: Every policy update gets a version number and date. Employees must acknowledge the current version annually.
• Plain language summaries: A one-page 'what this means for you' sheet for each major role, sales, HR, finance, operations.

Click to enlarge

Building and Maintaining Your AI Risk Register

A risk register is a living document, a structured catalog of every AI use case in your organization, the risks each one carries, and the controls you have in place to manage those risks. It is not a one-time exercise. New use cases get added when employees start using a new tool. Risk levels get updated when a tool's capabilities change or when an incident occurs. The risk register is what a regulator, auditor, or senior executive asks to see when they want evidence that your AI compliance program is real, not performative.

Start with an inventory. Survey department heads: what AI tools are your teams using, for what tasks, and with what data? You will almost certainly find shadow AI, tools employees adopted without formal approval. That is not a reason to panic; it is information. Bring those use cases into the register, assess their risk, and either formalize them with controls or discontinue them with clear communication. A risk register with 40 documented use cases and controls is far better than a clean sheet of paper that doesn't reflect reality.

1. Name the use case specifically: 'Sales team uses Gong AI to summarize customer calls', not 'AI for sales.'
2. Identify the data involved: customer names, call recordings, deal values, competitor mentions.
3. Assess inherent risk: What could go wrong if this use case has no controls? Rate High / Medium / Low.
4. Document existing controls: Is there a data processing agreement with Gong? Are call participants notified of AI recording? Is output reviewed before sharing?
5. Assign residual risk: After controls, what risk remains? This is the number that matters for prioritization.
6. Name the owner: Who is accountable for this use case staying compliant? A named individual, not a department.
7. Set review date: High-risk use cases reviewed quarterly. Medium reviewed semi-annually. Low reviewed annually.

Click to enlarge

Using AI to Draft Your Compliance Documentation

Vetting AI Vendors Before You Sign Anything

Every AI tool your organization uses is a vendor relationship, and vendor risk management applies just as much to a $30/month SaaS subscription as to a $300,000 enterprise contract. The critical question is data handling: does this vendor train their AI models on your inputs? Where is your data stored? Who can access it? Many popular AI tools have enterprise or business tiers specifically designed to address these questions. ChatGPT Team and Enterprise, for example, do not use your conversations to train OpenAI's models. The free tier does not offer the same protection. That distinction matters enormously for compliance.

Vendor vetting for AI tools should follow a consistent checklist regardless of cost or perceived risk. A 'free' AI tool that processes client data without a data processing agreement is not free, it carries regulatory and reputational liability that could dwarf the cost of a paid enterprise tier. Your procurement or legal team should maintain a standard AI Vendor Due Diligence Questionnaire. When vendors can't answer basic questions about data retention, model training, and subprocessor relationships, that is a red flag, not a reason to proceed cautiously, but a reason to stop.

Click to enlarge

Practical Task: Build Your First AI Risk Register Entry

Quick Reference: AI Compliance Program Cheat Sheet

• AI Use Policy must specify: approved tools by name and tier, prohibited data types, amber-list approval process, and incident reporting steps.
• Risk register covers: use case description, data types, inherent risk, controls, residual risk, named owner, review date.
• Vendor due diligence non-negotiables: model training terms, data residency, retention period, subprocessors, SOC 2 status, breach notification timeline.
• Free/consumer AI tiers are not covered by enterprise data agreements, require employees to use business or enterprise versions.
• Shadow AI is normal, audit without blame, then bring discovered use cases into the register with appropriate controls.
• AI compliance owner = one named person accountable for policy enforcement, vendor reviews, and incident response, not a committee.
• High-risk use cases (personal data, hiring, client data) reviewed quarterly. Medium semi-annually. Low annually.
• Incident response for AI: contain → report to compliance owner → assess data exposure → check external reporting obligations → correct → post-incident review.
• Policy updates every six months minimum. AI tool capabilities and regulatory guidance change faster than annual review cycles can track.
• Employee acknowledgment is not optional, keep records of who has read and confirmed the current policy version.

Key Takeaways from Part 2

• A functional AI Use Policy names specific tools and tiers, not just principles. 'Use AI responsibly' is not a policy.
• The risk register is the operational core of your compliance program, it documents reality, not aspiration.
• Vendor vetting applies to every AI tool, regardless of cost. Free tools often carry the highest data risk.
• Shadow AI is a data point, not a scandal. Inventory first, then build controls around what you find.
• One named owner for each AI use case eliminates the accountability gap that makes compliance programs fail.

You have the framework. Now you need the operational layer, the day-to-day mechanisms that keep your AI compliance program alive after launch. Most programs fail not at design but at execution: no one owns it, nothing gets reviewed, and the first incident catches everyone off guard. This section covers ongoing monitoring, incident response, and the audit practices that turn a paper policy into a working system.

1. AI compliance is a continuous process, not a one-time policy document.
2. Every AI tool in use needs an assigned owner responsible for monitoring it.
3. Incident response plans for AI must exist before an incident happens.
4. Audit logs, records of what AI tools were used, when, and by whom, are your evidence trail.
5. Regulatory requirements for AI are evolving fast; your program must have a review cadence built in.
6. Employees need refresher training, not just onboarding training, on AI use policies.
7. Third-party AI vendors carry compliance risk that your organization is still responsible for managing.

Ongoing Monitoring: Keeping the Program Alive

A compliance program without monitoring is just a filing cabinet. Ongoing monitoring means regularly checking that your AI tools are being used as intended, that outputs are accurate and unbiased, and that no new risks have emerged. This does not require technical expertise. It requires structured check-ins: monthly reviews of AI-assisted outputs in high-risk areas, quarterly surveys of staff about how they are actually using tools, and annual policy reviews aligned to any regulatory changes in your industry.

Assign a named AI Compliance Owner, a person, not a committee, for each business unit using AI tools. This person does not need to be technical. They need to be organized, have access to usage data from your IT or operations team, and be empowered to escalate concerns. In smaller organizations, one person can own this across the whole company. The key is accountability. Without a named owner, monitoring becomes everyone's responsibility, which means it becomes no one's.

• Review a sample of AI-generated outputs monthly in high-risk workflows (hiring, finance, legal, customer-facing content).
• Track which AI tools are in active use, shadow IT (unapproved tools) is a major compliance gap.
• Check vendor update logs: when ChatGPT, Copilot, or Gemini updates its model, your risk profile may change.
• Document every monitoring review, even if nothing is flagged. The record matters.
• Survey employees quarterly: 'Have you used any AI tools not on the approved list?' Anonymize it for honest answers.

Incident Response: When Something Goes Wrong

AI incidents happen. A hiring tool flags candidates in a discriminatory pattern. A chatbot gives a customer dangerously wrong information. An employee pastes confidential client data into a public AI tool. These are not hypotheticals, all three have occurred at real organizations. The question is not whether you will have an AI incident but whether you have a plan when you do. An incident response plan for AI follows the same logic as any other incident response: detect, contain, assess, remediate, report, and learn.

Your AI incident response plan should be a short, practical document, ideally one page, that anyone in the organization can act on. It defines what counts as an AI incident, who to notify first, how to suspend a tool if needed, what records to preserve, and whether regulators or customers must be notified. In regulated industries like finance, healthcare, and legal services, notification timelines are often mandated by law. Know your obligations before an incident forces you to find out under pressure.

1. Define what counts as an AI incident: inaccurate output causing harm, data breach via AI tool, discriminatory outcome, unauthorized AI use.
2. Name the first point of contact, one person or role, not 'contact IT or HR'.
3. Specify how to suspend or pause an AI tool immediately if needed (usually: stop using it and notify the owner).
4. List what records to preserve: screenshots, prompts used, outputs generated, timestamps.
5. Identify your regulatory notification obligations by industry and jurisdiction.
6. Require a written post-incident review within 30 days, even for minor incidents.
7. Feed lessons learned back into training and policy updates.

Click to enlarge

Audit Trails and Third-Party Vendor Risk

An audit trail is a record of what happened, when, and who was responsible. For AI compliance, this means keeping logs of which tools were used in which workflows, what prompts were submitted in sensitive contexts, and what outputs were acted upon. You do not need special software for this. A shared spreadsheet updated monthly, a folder of screenshots for high-risk decisions, or a Notion page with dated entries is enough for most organizations. The goal is to be able to answer a regulator's or client's question: 'How was this decision made, and what role did AI play?'

Third-party vendor risk is the most underestimated gap in most AI compliance programs. When your organization uses ChatGPT Plus, Microsoft Copilot, or Google Gemini, you are relying on those vendors' data practices, model behaviors, and security controls. Your compliance obligations do not transfer to them, they stay with you. Review your vendor agreements for data retention clauses, opt-out options for training data use, and breach notification commitments. Most major vendors publish these terms publicly. Read them, or have your legal team summarize the key points.

Cheat Sheet: Running an AI Compliance Program

• Name one AI Compliance Owner per business unit, accountability requires a person, not a committee.
• Maintain an approved tools list and update it every quarter; shadow IT is your biggest hidden risk.
• Review AI outputs monthly in high-risk workflows: hiring, finance, legal, customer communications.
• Keep a simple audit log, even a shared spreadsheet counts, documenting AI use in significant decisions.
• Write a one-page incident response plan before you need it; include who to call, what to preserve, and when to notify regulators.
• Check vendor data terms for free vs. paid tiers, free tiers typically have weaker data protections.
• Run an annual full policy review tied to any new regulatory developments in your industry.
• Refresher training matters more than onboarding training, most AI misuse happens months after staff are first trained.
• Third-party vendor risk is your responsibility, their breach is your compliance problem.

Key Takeaways

• AI compliance programs require ongoing monitoring, not just a policy document at launch.
• Every AI tool in use needs a named owner who is accountable for how it is used and what it produces.
• An incident response plan for AI should be written, tested, and accessible before any incident occurs.
• Audit trails do not require special technology, a consistent record-keeping habit is sufficient for most organizations.
• Free-tier AI tools carry greater data risk than paid or enterprise plans; audit which tier employees are actually using.
• Third-party vendors do not absorb your compliance obligations, you remain responsible for what their tools do in your workflows.
• Regulatory requirements for AI are evolving; build a scheduled annual review into your program from day one.