A chief information security officer at a mid-sized insurer is asked to sign a one-page attestation for the board: confirm that the AI tools now in use across the firm are governed. Not secure, which the CISO can already evidence, and not compliant with one named regulation, which compliance handles separately. Governed: who decides what the AI may answer from, who sees those answers, where the processing happens, and whether any of it can be reconstructed afterwards. Those questions are the substance of an AI governance framework, a phrase the CISO has used in a dozen slide decks. Asked to attest to it in writing, the gap between the words and the controls behind them suddenly matters.
This is the moment an AI governance framework stops being a policy document and becomes an architecture question. AI governance is the set of controls an organisation puts around its AI systems so that decisions about access, data, and oversight are deliberate, recorded, and defensible. For most enterprises, the AI tooling arrived faster than the controls did. The model was switched on, people found it useful, and the governance was assumed to follow. What regulated boards are now discovering is that governance cannot be retrofitted onto a tool that was never designed to be governed.
This guide sets out a practical AI governance framework for regulated enterprises. It covers why governance has become a procurement gate rather than a post-purchase exercise, the three layers any framework has to address, what an AI tier under genuine control actually looks like day to day, where general-purpose AI tools fail the test, and the questions a buyer should ask to separate platforms built for governance from those that bolt it on. It is written for the CTO, CIO, CISO, and compliance lead who will, between them, own the attestation when it lands.
Why an AI governance framework is now a procurement requirement, not a nice-to-have
For most of the last decade, AI governance lived in the policy function. It produced principles documents, ethics statements, and acceptable-use policies. These were necessary, but they governed intent rather than systems. The shift in 2026 is that governance demands now reach into the architecture of the tools themselves, and they arrive at the procurement stage rather than after deployment.
Three forces moved governance from aspiration to gate. The first is regulatory: standards such as ISO 42001, the AI management system standard published in 2023, and the EU AI Act, now applying in stages, expect organisations to demonstrate documented control over AI systems rather than assert it. The detail of the regulatory landscape sits in our guide to AI knowledge management for regulated industries; the point here is narrower. Regulators have stopped accepting a policy as evidence of governance. They want to see the controls.
The second force is internal accountability. When AI begins answering questions that inform regulated decisions, the board inherits responsibility for those answers. A board cannot accept responsibility for a process it cannot describe. The attestation the CISO is asked to sign is the visible end of a longer chain: the board wants assurance, the executive wants control, and control has to be built into the system rather than narrated around it.
The third force is the most practical. Buyers have learned, often the hard way, that a tool which cannot be governed becomes a liability the moment it is questioned. An ungoverned AI tool that produces a confident answer with no record of where it came from is not a productivity gain in a regulated firm; it is an unbounded source of risk. Procurement teams now screen for governance posture at the shortlisting stage, which is why enterprise AI governance has become a category buyers actively search for rather than a property they hope to find later.
The three layers of AI governance: model, knowledge, and audit
A useful AI governance framework separates the problem into three layers. Each answers a different question, each can fail independently, and a platform strong in one layer can be weak in another. Treating "AI governance" as a single property is the most common analytical error buyers make. The framework below is deliberately platform-agnostic; it describes what has to be controlled, not which product controls it.
The model layer: what the AI is and where it runs
The model layer governs the AI system itself: which model is used, who operates it, where the inference happens, and under whose contractual control. The governing questions are about provenance and jurisdiction. Is the model operated in-house or by a third party? In which jurisdiction does the processing occur? Is customer data used to train or improve the model, by the vendor or by anyone in its supply chain?
This layer is where the sovereignty conversation intersects governance, though the two are not the same thing. Sovereignty asks whose law reaches the data; governance asks whether the organisation has deliberately decided and recorded the answer. A firm can be perfectly governed at the model layer while accepting a US-controlled processing tier, provided that decision was made consciously and documented. The deeper jurisdictional argument lives in our sovereignty topic hub. For the governance framework, the model layer's test is simpler: can you state, on demand, what the model is, who runs it, and where.
The knowledge layer: what the AI is allowed to answer from
The knowledge layer is the one most governance discussions skip, and it is frequently the layer that matters most. It governs the corpus: which documents the AI is permitted to use when constructing an answer, who decided each document was eligible, and what happens when a document is superseded. Permission inheritance is not governance of this layer. A tool that answers from whatever a user can technically access has delegated the most important governance decision to file-system permissions set years ago for an entirely different purpose.
Genuine control at the knowledge layer means a document becomes eligible for AI answers through a deliberate act of approval, not by accident of access. This is the discipline of curation, which we explore in depth in our curated knowledge topic hub. The governing test: can you produce the list of documents the AI was allowed to answer from on a given date, with the named approval attached to each one?
The audit layer: what can be reconstructed afterwards
The audit layer governs evidence. After an answer has been given and acted upon, can the organisation reconstruct how it was produced? This means more than a query log. It means knowing which version of which document fed a specific answer, who had approved that version, and which user received it. The audit layer is what turns the other two layers from claims into demonstrable facts. Without it, model and knowledge governance are assertions; with it, they are records a regulator or an internal auditor can read.
What governance looks like when the AI tier is actually under control
It is easy to describe governance as a list of controls and harder to picture what it feels like in operation. An AI tier under genuine control has a few recognisable characteristics, and they are worth stating concretely because they are the difference between a framework that exists on paper and one that runs.
Documents enter the AI's reach through a decision, not a sync. When a new policy is approved, a named subject-matter expert marks it eligible, and that approval is written into the record at the moment it happens. When the policy is superseded, the old version stops feeding answers and the new one takes over, with the historical record of which version was canonical on which date preserved. Nobody has to remember to do this as a separate compliance task; it is how the system works.
Answers carry their provenance. Every response resolves to specific documents and versions, so a user reading an answer, or an auditor reviewing it months later, can see exactly what it was built from. The question "where did this come from" has a short, factual answer rather than a paragraph of reconstruction.
Access is deliberate and reviewable. The organisation can state who can ask the AI questions, what each person or group can receive answers from, and how that maps to the sensitivity of the underlying documents. External parties, where they have access at all, are governed by the same controls rather than by an exception nobody fully owns.
The common thread is that control is structural rather than procedural. Procedural governance depends on people following a process every time; structural governance is built so that the governed outcome is the default. Regulated firms have learned to distrust procedural controls precisely because they fail quietly under pressure. A governance framework is only as strong as its weakest procedural step, which is why the strongest frameworks remove the procedural steps wherever they can.
Where general-purpose AI tools fail the governance test
General-purpose AI tools, including the assistant and copilot products now bundled into productivity suites, are genuinely useful and are not the subject of criticism here for what they were built to do. The point is narrower and architectural: they were built to be helpful across an open corpus, and the properties that make them helpful are in direct tension with the properties governance requires.
Consider each layer in turn. At the knowledge layer, a general-purpose tool typically answers from everything a user can access. This is the opposite of curation. There is no approval step, no eligibility decision, and no way to produce the date-stamped list of permitted sources, because no such list was ever created; the corpus is simply defined by file permissions. At the audit layer, these tools generally produce usage telemetry rather than per-answer provenance. You can often see that a user asked something; you cannot reliably reconstruct which version of which document produced the answer they acted on. At the model layer, the processing frequently happens in a jurisdiction and under a contractual arrangement the buying organisation has limited visibility into.
None of this makes general-purpose AI tools bad products. It makes them ungoverned by default, which is a different statement. A firm can deploy them perfectly well for low-stakes work where the governance demands are minimal. The failure mode is using them for policy-critical or regulated queries, where the answer might inform a decision the firm has to defend, without the controls those queries require. The broader category shift from open search to governed organisational knowledge is the subject of our guide to enterprise AI search in 2026. For the governance framework specifically, the lesson is that openness and governability are design choices in tension, and a tool optimised for one will struggle at the other.
This is also why "we already have an AI tool, can we just govern it" is usually the wrong question. Governance that the architecture does not support cannot be added through configuration. The realistic options are to scope the existing tool to ungoverned work and procure a governed layer for the queries that need one, or to replace it. Either way, the decision belongs at the procurement stage, which returns us to the buyer's checklist.
Evaluating an AI knowledge platform's governance posture: buyer's checklist
The following questions are organised by the three layers. They are deliberately about governance posture rather than the regulatory-mapping questions a compliance evaluation asks; the two checklists are complementary, and the regulatory one lives in our regulated-industries guide. Asked together, these questions separate platforms built for governance from those that present it as a feature.
Model layer. Where does the AI processing run, and under whose contractual control? Is the model in-house or third-party, and is that disclosed? Is customer data ever used to train models, by the vendor or anyone in its supply chain? Can the buyer choose the jurisdiction of processing, and is that choice contractually guaranteed rather than best-efforts?
Knowledge layer. Does a document become eligible for AI answers through an explicit approval, or by permission inheritance? Can the platform produce the curated source set as it stood on a specific past date, with the approver for each document? When a document is superseded, does the platform stop using the old version automatically, and is the supersession recorded? Who owns the eligibility decision, and is it a role the organisation controls?
Audit layer. Are answers cited at the level of specific documents and versions, or summarised with a generic source block? Can the platform reconstruct, for a given answer on a given date, the documents, versions, approvers, and recipient? Is the audit record produced natively as a by-product of normal operation, or assembled on request from logs?
Across all three. Is governance the platform's organising principle or a configuration option? A platform that treats governance as central will answer these questions crisply and in writing. A platform that bolted governance on will answer some of them with a roadmap. The distinction matters because the questions a board asks after an incident are not negotiable, and a roadmap is not an audit trail. This is the difference between buying AI governance software and buying a tool that hopes to be governable later.
How AnswerVault delivers governed AI as the product, not a feature
AnswerVault is a governed AI knowledge layer that connects an organisation's existing document sources, including SharePoint, Google Drive, and Confluence, and delivers source-backed answers through web chat, Microsoft Teams, Slack, CLI, and API. Governance is not a module within it. It is the organising principle the product was built around, which is the practical meaning of treating governance as the product rather than a feature.
At the knowledge layer, a document does not become eligible for AI answers because it sits in a connected source. It becomes eligible because a named subject-matter expert approves it, with the approval written into the audit trail at the moment it happens. When a document is superseded, the new version takes over and the record of which version was canonical on which date is preserved. This is the architecture that lets the platform answer "which documents was the AI allowed to use on this date, and who approved them" as a matter of record rather than reconstruction.
At the audit layer, citations resolve to specific documents and versions. An answer carries its provenance, so a user or an auditor sees what it was built from without a separate investigation. At the model layer, the platform is structured in tiers, and the jurisdictional answer depends on the tier. The Enterprise sovereign tier is UK-controlled and operated contractually outside the reach of the US CLOUD Act; for that tier specifically, the AI processing layer sits inside the sovereign boundary, not only the data at rest. Standard tiers run on managed AI infrastructure with EU and UK data residency. AnswerVault is ISO 27001 aligned and ISO 42001 underway; AI is included in every plan, with no per-query charges and no requirement to supply your own model. Customer data is never used to train models, by AnswerVault or by our foundation-model providers. The full technical posture, including subprocessors and attestations, is documented on our security and compliance page for procurement teams to reference directly.
The result is that the three governance layers are addressed by design rather than assembled by the buyer. That is the distinction this guide has argued matters most: governance that the architecture supports, rather than governance a process is asked to maintain.
Next steps
If you are the person who will eventually sign the attestation, the most useful first move is to map your own AI tooling against the three layers in this framework and mark where each control is structural, procedural, or absent. The absent and procedural entries are the work. For the procurement view across the wider category, our guide to enterprise AI search in 2026 walks through the evaluation with regulated buyers in mind.
Read our curated knowledge guide for the capability beneath the knowledge layer, or see how these controls work in practice on the AnswerVault product page.
AnswerVault is built by Catapult CX, an enterprise technology consultancy. The product was originally developed for a global pharmaceutical company with strict data governance requirements; the same architecture now powers the SaaS platform.