Governance sovereignty: who owns your AI policies, audit trail and evidence

What is governance sovereignty?

Governance sovereignty is one of the seven kinds of sovereignty: policies, permissions, oversight, audit and evidence. The brief puts it plainly: the rules, the oversight and the proof stay with you, not with a vendor.

It is easy to overlook because governance feels like an internal matter. But consider where the pieces actually live. The policy engine may be a vendor feature. The audit log may sit in a vendor's database. The evidence a regulator asks for may require a support ticket to extract. An organisation in that position has governance in name and dependence in practice. This is the failure mode this page is about, and the reason governance is a fabric running through all six layers rather than a seventh layer on top.

Who should own the policy engine, the audit trail and the evidence?

You do not have to build every component. You do have to hold the decisions and the records. The table separates what is acceptable to buy from what you should be able to take with you.

A good test: if the contract ended tomorrow, could you still show a regulator what your AI did last year? If the answer depends on the vendor's cooperation, governance sovereignty is incomplete. The same logic applies to supply-chain sovereignty.

What is wrong with vendor-held logs?

Logging is the most common governance control and the most commonly misunderstood. Having logs is not the same as being able to use them. Several things go wrong when logs live only in someone else's system.

• Retention you do not set. The vendor's default may be shorter than your obligation or longer than your privacy policy allows.
• Access you do not control. Retrieval may be limited to a dashboard, a rate-limited API or a support request.
• Content you cannot correlate. Logs that record a model call but not the policy applied, the data accessed or the downstream action cannot rebuild a decision.
• Integrity you cannot show. Reviewers may ask how you know the record is complete and unaltered. Be careful what you promise here. Platforms should describe their logging accurately, and Swfte makes no tamper-proof claim for its audit logs. See the trust centre.
• Lifetime tied to the contract. When the relationship ends, so may the history.

The remedy is simple to state. Require an export or streaming path for audit events into storage you control, in a documented schema, with identifiers that tie the events to your own systems. The AI compliance monitoring post shows how to automate evidence collection from those events.

What evidence does a reviewer actually ask for?

Auditors, regulators, customers and your own risk function ask versions of the same questions. Build the record around them, and the evidence assembles itself. The brief's definition of governance is a useful checklist: who is acting, allowed to do what, under which policy, with which data, using which model, at what risk, with what oversight, and can we prove it?

For each AI system the Trust Profile holds the static half of this record. The runtime log holds the dynamic half. The two together are what runtime governance produces as a by-product of enforcing policy.

What does the EU AI Act say about logging and oversight?

The EU AI Act is Regulation (EU) 2024/1689. Three articles bear directly on governance sovereignty for high-risk systems. This is a summary for orientation, not legal advice, and you should check the Official Journal text for anything compliance-critical.

• Article 12, record-keeping. High-risk systems must technically allow automatic recording of events over their lifetime, at a level of traceability suited to their purpose. See this explainer on Article 12 (opens in a new tab).
• Article 14, human oversight. High-risk systems must be designed so that people can effectively oversee them, including being able to intervene or stop them.
• Article 26, deployer obligations. Deployers must keep the logs generated by a high-risk system, to the extent they control them, for a period appropriate to the purpose and at least six months unless other law says otherwise. Secondary sources such as Legalithm (opens in a new tab) explain the six-month point.

Timing has moved. The Digital Omnibus on AI, Regulation (EU) 2026/1744, entered into force on 27 July 2026. It defers the stand-alone Annex III high-risk obligations from 2 August 2026 to 2 December 2027, and obligations for AI embedded in regulated products under Annex I to 2 August 2028, according to Gibson Dunn (opens in a new tab). General-purpose AI obligations and the general transparency obligations were not deferred in the same way. The obligations themselves are unchanged. Building the record now is cheaper than retrofitting it later. See also the EU AI Act overview.

Notice what the articles assume. Article 26 refers to logs a deployer controls. A deployer who cannot get at the logs cannot meet the point, whatever the vendor dashboard shows. That is governance sovereignty expressed as a legal requirement.

How do NIST AI RMF and ISO/IEC 42001 relate?

Two frameworks come up in almost every governance conversation. Neither is something a platform can confer on you. Both are things an organisation may adopt, and they are complementary.

• NIST AI Risk Management Framework 1.0, released on 26 January 2023, is voluntary and built around four functions: Govern, Map, Measure and Manage. Govern is the function that spans the whole organisation, covering accountability, policies and oversight. Map, Measure and Manage apply to individual systems. The NIST AI RMF Playbook (opens in a new tab) offers suggestions per outcome. Swfte's NIST AI RMF page maps the functions to platform controls.
• ISO/IEC 42001:2023 is the international standard for AI management systems. It sets requirements for establishing, implementing, maintaining and continually improving an AI management system, and has a certifiable audit path. See ISO's page on the standard (opens in a new tab). Organisations pursue it for their own management system.

For governance sovereignty, the useful reading is practical. Both frameworks assume you can document roles, risks, controls and monitoring, and show records that the controls operated. If the records sit with a vendor, adopting a framework is harder.

What does compliance-by-design mean here?

No platform can make your AI lawful by itself. Compliance depends on what you use AI for, where, and how it is configured. What a platform can do is provide the controls and the evidence, built in, so that your obligations can be met without bolting on tools afterwards. This is the position Swfte takes:

For what Swfte can show today, what is in progress and what it does not claim, read the trust centre. The governance layer describes the controls, and the AI governance page covers the use cases. For the build sequence, see step 7 of the guide, wire the trust fabric, and the related distinction in governance versus guardrails.