The request arrives in a leadership meeting, usually phrased as an afterthought. "We need an AI governance framework. Can security own it?"
You do. You write a policy. It says employees should not put confidential data into unapproved AI tools. Legal reviews it. HR distributes it. Everyone acknowledges it in an annual training.
Two weeks later, a finance analyst pastes a draft earnings summary into an AI assistant to tighten the wording. The policy was in her inbox. It did not stop her. Nothing was designed to.
That is the gap between an AI governance policy and an AI governance framework. A policy states intent. A framework assigns ownership, inventories what exists, decides what is allowed, enforces it, and produces proof. This post lays out a 90-day plan to build that, in the order that actually works.
What an AI Governance Framework Is
An AI governance framework is the set of roles, rules, processes, and controls that decide how an organization selects, uses, monitors, and answers for AI. It covers the AI you build, the AI you buy, and the AI your people use whether or not you approved it.
Most guidance converges on the same structure. The NIST AI Risk Management Framework, published in January 2023, organizes the work into four functions: Govern, Map, Measure, and Manage. Govern spans the whole organization and sets accountability and policy. Map identifies context and risks for each AI system. Measure produces evidence about those risks. Manage acts on that evidence. ISO/IEC 42001, published in December 2023, defines requirements for an AI management system, including risk management, impact assessment, lifecycle management, and third-party oversight.
You do not need to adopt either wholesale to benefit. What they share is the shape: ownership, inventory, decisions, controls, and evidence. The 90-day plan below follows that shape.
A practical point on regulation. The EU AI Act's transparency obligations under Article 50 apply from August 2, 2026, while obligations for high-risk systems have been pushed back under recent changes. Timelines are moving. Check current dates with counsel before you build a program around any single one.
đź“ť A Policy Says What You Intend. Evidence Shows What Happened.
Governing AI comes down to what each AI tool can read. See how per-file protection answers that for your own files in a two-week pilot.
Why Policy Alone Fails
Three things make AI different from earlier technology waves.
AI arrives through the side door: Most AI use starts with an individual signing up, not a procurement process. By the time you hear about a tool, it already holds data.
The data is files: The material people paste or upload into AI tools is contracts, models, designs, and drafts. Gartner estimates 70 to 90 percent of organizational data is unstructured, growing 40 to 60 percent a year. That is the data your controls cover least well.
Evidence is expensive after the fact: IBM reports the average cost of a data breach involving shadow AI at $5.39 million, reflecting the extreme difficulty of auditing what unapproved AI tools accessed after the fact.
The conclusion is not that AI is uncontrollable. It is that governance has to reach the data, not just the people.
The 90-Day Plan
Days 1 to 30: Own It and Inventory It
Name one accountable owner: Governance without an owner is a document. Pick a named person with authority across security, legal, IT, and the business units. A small council of those functions helps, but a single name is what makes decisions happen.
Write a one-page charter: What is in scope (AI you build, buy, and that employees use), who decides, and what escalation looks like. One page. If it takes longer, you are writing policy, not charter.
Inventory AI use: You cannot govern what you cannot see. Build the first list from four sources: procurement and licensing records, single sign-on and application logs, network and browser data, and a short survey of team leads. Expect the list to surprise you.
For each tool, record: what it is, who uses it, what data it touches, and whether it was approved.
Inventory the data that matters: Identify the file types and cloud repositories (SharePoint, Google Drive) containing sensitive data. Platforms with continuous discovery and agentic classification automate this process by continuously auditing repositories, mapping permissions, and sorting assets into data tiers.
End of day 30: a named owner, a one-page charter, an AI inventory, and a first list of protected data categories.
Days 31 to 60: Decide What Is Allowed
Set a decision for each AI use case, not a blanket rule. Three outcomes cover most of them:
| Decision | What it means | Example |
|---|---|---|
| Allow | Approved tool, approved data | Enterprise AI assistant, internal non-sensitive content |
| Limit | Approved for specific users, data tiers, or purposes | Legal team only, no client files |
| Block | Not permitted for this data | Personal AI accounts with Restricted data |
Tie decisions to data tiers: The unit of policy is not the tool. It is the combination of tool and data. A tool approved for internal notes may be forbidden for client contracts. Policies that name only tools are out of date within a quarter.
Write the acceptable use rules in plain language: Two pages, written for the person at the keyboard. Our guide to an AI acceptable use policy covers what the document needs to contain for defense contractors and, by extension, anyone with similar obligations.
Define third-party and vendor requirements: What must a supplier tell you before you send them data? Where does your data go, who can read it, and is it used to train models? Put the questions in your procurement checklist.
Decide how you will handle exceptions: There will be requests for tools you did not approve. A clear, fast path stops people from bypassing you.
End of day 60: a decision for each AI use case, policy tied to data tiers, plain-language rules, and a vendor checklist.
Days 61 to 90: Enforce and Prove
This is where most frameworks stop short. Policy is written, people are trained, and the plan ends. Enforcement and evidence are what separate a framework from a document.
Pick the enforcement points: Network controls, browser controls, and identity policies each govern some of the path. They share a limit: they see where data is going, and they cannot see what the destination receives once the connection is encrypted.
We covered that blind spot in How to Stop Sensitive Files Entering ChatGPT, Copilot, and Gemini.
Add a control at the file: This is the layer most programs lack. If each sensitive file is encrypted with its own key and opens only for an approved identity, an AI tool that is not approved cannot read the data. The file enforces the decision wherever it ends up. The tool does not need to be on a blocklist.
Our deeper treatment is in What Does AI Data Governance Require at the File Layer?.
Decide what evidence you will keep: Regulators, customers, insurers, and boards ask the same questions: which AI tools can reach which data, who approved it, and what happened. Build the record now. For files, that means a log tied to the file: which identity tried to open it, from where, and whether access was granted or refused.
Our post on file access audit logs covers what a useful record contains.
Test it. Pick five Restricted files. Try to get each into an unapproved AI tool. Record what happens. Run the test quarterly.
Set a review rhythm. Quarterly is enough to start. Review the AI inventory, the exceptions log, and the evidence. Update the tier decisions.
End of day 90: enforcement in place at more than one layer, an evidence record, a test you can repeat, and a review calendar.
Where Theodosian Fits, and Where It Does Not
The framework above is bigger than any one product, and it should be. A few points on where Theodosian sits.
Theodosian spans the full pipeline—Discover, Protect, and Govern. It continuously inventories cloud storage, uses agentic engines to classify sensitive files, and enforces access policy—from AI egress rules to per-file encryption. Opening a protected file requires an access decision, and every attempt is recorded in a per-file access log.
The Honest Limits
Theodosian provides continuous discovery, agentic classification, and file-layer protection. We believe in being transparent about what our architecture does and does not do:
- In-Use Content Restrictions vs. Full DRM: We control who can open and decrypt a file based on context (identity, device, location, time). Once an authorized user opens an unencrypted view in a native application, we do not restrict screen capture, printing, or physical text copying (full DRM features are on our roadmap).
- Unstructured Files vs. Relational Databases: Our pipeline is built specifically to discover, classify, and protect unstructured files (documents, spreadsheets, PDFs, code) across cloud storage. It does not inspect or encrypt relational databases.
- Governance Scope: While we continuously discover sensitive files and enforce access policies, we do not write your organizational compliance policies, assign internal administrative owners, or replace network and identity security controls.
Common Mistakes
Starting with the policy document. A policy written before you know what exists describes a company you do not have. Inventory first.
Governing tools instead of data. Tool lists go stale fast. A rule tied to data tiers survives new tools.
Treating "block it" as a plan. Blocking drives use to personal devices and personal accounts, where you lose visibility entirely.
Skipping the owner. A council with no single name rarely decides anything.
Not testing. A control you have not tried to defeat is a guess.
Forgetting that AI agents are users too. An AI agent acting on someone's behalf is an identity with access. Include non-human identities in your inventory and in your evidence. Our post on agentic AI governance gaps goes deeper.
What This Means for Your Security Program
A governance framework is not a document. It is a loop: know what exists, decide what is allowed, make the decision enforceable, and keep the proof.
The first two steps you can do with spreadsheets and meetings. The third and fourth need controls that work on the data itself, because the data is what leaves, and what leaves is what you will be asked about.
Your controls end where the file does, and the file leaves the container every single day. Governance that stops at the container stops short of the data.
Build the Evidence Layer in Two Weeks
We run a two-week pilot on a defined set of your Restricted files. You choose them. We show you how it works.
FAQs: AI Governance and File-Layer Evidence
Is Theodosian an AI governance platform?
Theodosian provides the technical pipeline for AI data governance by unifying continuous discovery, agentic classification, and file-layer enforcement. It discovers sensitive files across cloud repositories, maps access exposure (including AI agent permissions), and controls what AI tools can read through context-aware policies and per-file encryption.
What does an unapproved AI tool actually receive if someone uploads a protected file?
Nothing. The file is encrypted with its own key, and opening it requires an access decision against your policy. An unapproved tool is not an approved identity, so it cannot read the file. In the pilot, you test this on your own files: upload a protected file to an unapproved tool and see what comes back.
Can we allow Copilot but block personal AI accounts for the same files?
Yes, on the files Theodosian protects. Policy can approve a governed application on a managed device and refuse requests from personal accounts or unmanaged devices, with each decision evaluated at the moment of the request. In the pilot, we configure that on your files and show the result for both.
Does Theodosian stop employees from pasting text into AI tools?
No. Theodosian controls who can open a file. It does not prevent an authorized user from copying content once the file is open, because rights management is on the roadmap and not shipped. If someone opens a file legitimately and pastes what they see, that text is outside the file's control. Pair file-layer controls with policy, training, and network or browser controls.
What evidence does Theodosian produce for an AI governance review?
A per-file record of each attempt to open a protected file: the identity, the device, the location, the time, and whether access was granted or refused. That is useful evidence for an auditor, customer, or board asking what an AI tool could reach. It supports your evidence. It does not by itself satisfy any named framework.
What would a two-week pilot show us?
We protect a defined set of your Restricted files over your existing Microsoft 365, Google Workspace, or cloud storage, with no data migration. You see what an approved AI application receives, what an unapproved one receives, and the per-file record of each attempt from your own environment. You finish with a direct answer to the question a policy cannot answer: what could the AI tool actually read?
Related Reading:
What Does AI Data Governance Require at the File Layer?
Best AI Governance Tools in 2026: A Security Team's Guide
Shadow AI Data Governance: The Hidden Pipeline Your Security Stack Was Never Built to See
How Do You Protect the Files Feeding Your AI Systems?
🔍 Contractor Access Audit: Contractors use AI tools with your files too. Use our Contractor Offboarding File Security Checklist to find out which copies are still out there.
🤖 AI Access Audit: Start your inventory here. Use our Shadow AI Risk Assessment Checklist to map where AI touches your files.