What is AI governance?
AI governance is the set of controls, policies, and records an organization places around its use of AI so it can answer four questions at any moment: what data was sent to which model, why a particular response was produced, who had the authority to approve it, and which rules applied.
Calling an AI API is not the same as controlling it. A model behind an endpoint gives you capability, but no visibility into what your applications send, no enforcement of your own rules, and no audit trail you own. AI governance is the operational layer that supplies all three — at the point each request is made, not in a quarterly review.
Why it matters now
Teams adopt AI faster than they govern it. A system ships, it works, and months later someone asks what data was sent to the model last Tuesday and who approved a particular output — and there is no answer. That problem is operational, not legal: no visibility into what AI systems send, no record when something goes wrong, no control over what data reaches external models. It exists whether or not you are regulated.
Regulation like the EU AI Act adds urgency and a deadline, but it is one reason among several, not the whole point. The goal of AI governance is control — over your data, your rules, and your evidence. Compliance, where it applies, falls out of that control as a by-product.
One lens: the EU AI Act risk tiers
Regulation is one useful lens on AI risk, and the EU AI Act is the clearest example. It regulates AI by risk tier, applying based on whether your AI is used by or affects people in the EU — not on where your company is located. The tiers are a practical way to think about any AI use, regulated or not. Simplified:
| Tier | Examples | Obligation |
|---|---|---|
| Unacceptable | Social scoring, manipulative techniques, untargeted biometric scraping | Prohibited |
| High risk | Employment, credit & insurance, education, medical, justice, critical infrastructure | Strict controls, documentation & human oversight |
| Limited | Chatbots, emotion systems, synthetic media | Transparency / disclosure |
| Minimal | Most other uses | Few or no obligations |
Mapping your use cases to tiers
The practical first step is to map each AI use case to a risk tier — because the tier decides which rules apply. This is hard to do by hand at request scale, which is why governance tooling classifies automatically. Praetor's classifier maps every request to one of 17 regulated categories (biometric surveillance, employment, credit & insurance, medical, justice, and more), and you set the outcome per category — see the policy engine.
GDPR and AI
When prompts contain personal data, GDPR applies the moment that data crosses your boundary to an external model — typically a third-party processor in another jurisdiction. Three principles matter most:
- Data minimization. Send the model only what it needs. Detect and pseudonymize personal data before it leaves, then restore it on the response so users still see real values.
- Pseudonymization is not anonymization. Replacing identifiers with reversible tokens reduces risk and is recognised by GDPR, but the data remains personal data while the mapping exists — so that mapping must be protected and kept out of the provider's reach.
- Quasi-identifiers (Recital 26). A person can be singled out with no explicit identifier — "the only dentist in a small town near Niš." Effective protection has to catch meaning, not just patterns like emails or card numbers.
Prompt injection and adversarial input
Governance is not only about data and policy — it is also about the integrity of the request itself. Prompt injection is input crafted to override a model's instructions or hijack its behavior, for example to exfiltrate context or bypass guardrails. In a governed pipeline, every prompt is scored for injection before it reaches the model, and a high-confidence detection can be flagged or escalated to a human according to policy — turning a silent attack surface into a logged, reviewable event.
A practical AI governance checklist
- Inventory every AI system. You cannot govern what you have not listed. Record provider, use case, and owner.
- Discover and block shadow AI. Detect unregistered tools and stop traffic until they are reviewed.
- Classify each use case into a risk tier so the right rules apply automatically.
- Write policies as enforceable rules — allow, hold for human review, or block — not a PDF no system reads.
- Protect sensitive data before it reaches any external model, including contextual identifiers.
- Screen for prompt injection on every request.
- Put a human in the loop for high-risk requests and, where needed, for responses too.
- Record everything immutably — every request, decision, and reviewer, with tamper-evident, exportable evidence.
Common pitfalls
- Governance as a document. A policy that lives in a PDF governs nothing; rules must be enforced at the request, automatically.
- Pattern-only PII. Regex catches emails and card numbers but misses names in context and quasi-identifiers — the data that most often re-identifies people.
- No inventory. Without a registry of AI systems, shadow AI is invisible and ungovernable.
- Logs you can't trust. An audit trail that can be edited after the fact is not evidence. Integrity has to be cryptographically verifiable.
- All-or-nothing enforcement. Blocking everything kills adoption; blocking nothing defeats the point. Governance is per-use-case, graded — allow, review, block.
Where Praetor fits
Praetor turns this checklist into enforced infrastructure. It is a governance gateway that sits between your applications and the AI providers you use: it inventories and discovers AI systems, screens for injection, pseudonymizes PII, classifies each request, applies your policies, routes high-risk cases to a reviewer, and writes an immutable audit trail — via a one-line API-proxy change or a Desktop Client with no code changes.
Read the technical documentation, or request early access.
Frequently asked questions
What is AI governance?
The controls, policies, and records around an organization's use of AI so it can prove what data was sent to which model, why a response was produced, who approved it, and which rules applied — enforced at every request, not reviewed quarterly.
How is it different from AI compliance?
Governance is the ongoing operational control; compliance is demonstrating that control satisfies a specific obligation such as the EU AI Act or GDPR. Governance is the machinery; compliance is the evidence it produces.
Does the EU AI Act apply to my company?
It applies based on the risk of the use case and whether your AI is used by or affects people in the EU, regardless of where you are based. But governance is worth doing regardless: the operational need for control — visibility, data protection, an audit trail — exists even where no regulation applies.
What is Shadow AI?
Any AI tool used without approval or registration — an employee pasting customer data into a consumer chatbot, for instance. It is a risk because no one has reviewed what it does or what data it handles; governance tooling discovers, blocks, and surfaces it for review.