Compliance is architecture.
AI governance at Pexon is built rather than documented. We route AI traffic through one gateway, intercept personal data and secrets before they leave, log prompts and outputs to an audit standard, and where the law requires it run open-weight models entirely inside your own data centre.
Built rather than documented.
Most AI governance programmes start with a policy document and end with a policy document, while the systems they are meant to govern keep shipping. The obligations that actually bite are technical: knowing which data went into which output, being able to show it to an auditor, and being able to stop a class of use the day it becomes a problem. Those are build decisions, not writing decisions.
Our answer is architectural: route AI traffic through one gateway, intercept personal data and secrets before they leave, log prompts and outputs to an audit standard, and where the law or the data classification requires it, run open-weight models entirely inside your own data centre. Everything below is one of those four builds.
Governance decided late is governance that fails.
A system that shows everyone everything cannot go to production, and no amount of documentation fixes it afterwards. The entitlement model and the audit trail are part of the first sprint, because retrofitting access control into a retrieval platform is a rebuild, and retrofitting an audit trail into a production system means re-architecting the data path.
The second reason for the order is that governance and delivery are the same work here. The gateway that logs everything is also the gateway that routes to the cheapest model and the one that can block a rogue application. You do not build governance on top of a working system — you build the system governed, which costs the same and fails differently.
Everything else is a policy document.
When we scope a governance engagement, the work reduces to four decisions. Each one is a thing that exists in the system and can be demonstrated, which is the only kind of compliance evidence an auditor cannot argue with.
| Decision | What it means in the system |
|---|---|
| One gateway for all AI traffic | Every prompt and output — from pilot apps, embedded copilots, even unapproved tools — crosses one gateway that can see, route and stop it. You cannot govern traffic you cannot observe. |
| PII and secret interception | Personal data and credentials are detected before they leave the boundary, in the request path, not in a policy document. The block is enforced by the gateway, so it applies to every application at once. |
| Audit-grade logging | Prompts, outputs, model, latency and the identity behind the request are logged to the standard your auditors actually ask for. When the question is "what data went into which output", the answer exists in writing. |
| EU AI Act readiness | Where the law requires processing inside your own estate, open-weight models run on your hardware with retrieval and access control bound to your existing directory — the capability is built, not promised. |
The risk is not the tool. It is that nobody can see the traffic.
Employees are using AI whether the IT department knows it or not — pasting customer records into public chat tools, running code through consumer assistants. Blocking every tool by policy does not stop the behaviour; it stops the visibility, which is worse. The gateway is the answer because it sees the traffic regardless of which tool generated it, and it can apply the same interception and logging rules to all of it.
The shadow AI lockdown engagement is the practical version: discover what is being used, route it through the governed path, and block only the traffic that cannot be governed. The default state is visible, not forbidden.
When the law or the contract forbids the cloud, the model moves in.
Some workloads cannot be sent to a vendor API, however compliant the vendor claims to be — the data classification forbids it, a customer contract requires processing inside your own estate, or the EU AI Act obligations for the use case demand full control. For those, open-weight models run on your own hardware, with retrieval and access control bound to your existing directory. The path is covered in the sovereign private AI engagement, and the regulatory timing on the EU AI Act readiness page.
None of this requires waiting for a policy round. The gateway, the interception and the logging are the same architecture whether the model behind them is a vendor API or an open-weight model in your data centre — which is why governance and private AI are one engagement, not two.
Governance capabilities
EU AI Act Readiness — Classification, Logs, Eval Evidence
Risk classification under Article 6 and Annex III, event logging that meets Articles 12 and 19, and evaluation evidence produced on every release.
Shadow AI Lockdown — One Gateway, Full Audit Trail
Unauthorised AI endpoints found across corporate proxies, replaced by one internal gateway with PII interception and audit-grade logging.
Sovereign Private AI — Open Weights in Your Own Data Centre
Open-weight models and vector search running on your hardware, with GPU sizing, quantisation and local access control bound to your directory.
Common questions
Is a policy document not enough for the EU AI Act?
Not for a system in production. The obligations that bite are technical: knowing which data went into which output, being able to show it, and being able to stop a class of use. Those are build decisions.
Our public cloud use is restricted. Is that a blocker?
No. Where the data classification or the law requires it we deploy open-weight models on your own hardware, with retrieval and access control bound to your existing directory.
Not a sales call. An architecture call.
Thirty minutes with the architect who would actually run the engagement.