AI Governance
Who decides, by which rules, with what proof
The set of policies, roles, processes and controls that determine who manages an organisation's AI systems, by which rules and with which checks, from idea to retirement.
One team wires an LLM into customer support, another trials a model for CV screening in HR, and marketing pastes a customer list into a chat assistant. Everyone means well; but if nobody knows how many AI systems the company runs, which ones process personal data, or who is accountable when one fails, the problem comes back one day as a data leak or a regulator's letter.
AI governance is the framework that stops those answers being left to luck. It has four layers: - Policies: what is allowed and what isn't? An acceptable use policy, prohibited use cases, data classification rules, rules for third-party models and vendors. - Roles and accountability: every system has an owner. Above them there is usually an AI committee or a Chief AI Officer (CAIO), with legal, security, data protection, risk and the business at the table. Who decides is written down. - Processes: how a new use case is proposed, how it is risk- classified, who approves it, which tests run before deployment, how it is monitored in production, when it is retired. - Controls and evidence: an inventory (AI system register), model cards, evaluation reports, human oversight, logs and audit trails. Saying "we did it" is not enough; you need to be able to show it.
The framework covers the whole lifecycle: idea → data → build or buy → test → deploy → monitor → change → retire.
How it differs from responsible AI: responsible AI describes principles — fairness, transparency, safety, privacy. Governance is the machinery that makes those principles operational: who applies them, how they are measured, what happens on a breach. Principles without governance are a web page; governance without principles has no direction.
Why now? External frameworks have become concrete: the EU AI Act imposes binding obligations, and voluntary frameworks such as the NIST AI RMF and ISO/IEC 42001 describe how to build governance. In Turkey, any AI use that processes personal data already falls under KVKK (Law No. 6698), and the Turkish DPA's recommendations on AI and personal data are a useful starting point. This page is informational, not legal advice.
Like medication management in a hospital. Which drugs are in stock (inventory), who may prescribe (roles), a double signature for high-risk drugs (approval process), adverse-event reporting (monitoring) and disposal of expired stock (retirement) are all written down. Doctors still treat freely; but when something goes wrong, "who gave this, why, and where is the record?" always has an answer.
A mid-sized e-commerce company notices its teams use dozens of AI tools. Over six months it does the following:
1. Inventory: every team logs its AI systems in one register: purpose, owner, model/vendor, data types, affected users. The first count finds 40 systems; 9 process personal data. 2. Risk classification: each system is tagged low / medium / high. The CV screening tool comes out "high" (they also hire in the EU, so it is high-risk under the AI Act too). 3. AI committee: a small board of legal, information security, the data protection officer and product leads meets monthly; every new high-risk use goes through it. 4. Controls: high-risk systems need a model card, a bias evaluation, human sign-off and a quarterly review. The deploy pipeline gets a check that refuses to ship a model with no register entry.
The result: teams still experiment fast, but every system now has an owner, a risk tier and an evidence file.
# ai-register/cv-screening.yaml
id: AI-017
name: CV pre-screening assistant
owner: people-team@example.com # business owner (accountable)
tech_owner: ml-platform@example.com # technical owner
purpose: Pre-rank applications against job criteria
lifecycle_stage: production # idea | pilot | production | retired
provider: third-party # in-house | third-party
model: "vendor-x/screening-v3"
personal_data: true
data_categories: [name, education, work history]
affected_people: job applicants (TR + EU)
risk_tier: high # internal classification
eu_ai_act: "Annex III — employment (high-risk)"
human_oversight: "Every rejection is confirmed by an HR specialist"
controls:
model_card: docs/model-cards/ai-017.md
bias_eval: reports/ai-017-bias-2026-09.pdf
dpia: legal/dpia/ai-017.pdf
approved_by: ai-committee
approved_on: 2026-09-12
next_review: 2026-12-12# Generative AI Acceptable Use Policy (v1.2)
## Allowed
- Drafting, summarising and coding with assistants on the approved list
- Working with public or "internal" classified data
## Not allowed
- Pasting customer personal data into unapproved tools
- Sending AI output to customers without human review
- Using AI for automated decisions about staff (hiring,
performance) — without AI committee approval
## For a new AI use case
1. Open an entry in the AI system register
2. Fill in the risk pre-assessment
3. Medium/high risk → AI committee approval
Owner: Chief AI Officer · Review: every 6 months- More than one team in the organisation builds or buys AI systems
- AI processes personal data or makes decisions about people (hiring, credit, health, education)
- You sell into the EU or produce outputs that are used in the EU
- Customers, investors or auditors have started asking for evidence of how you use AI
- Setting up a heavy committee and approval chain for a one-person hobby project — the burden is disproportionate
- Treating governance as a policy PDF; an unenforced policy is worse than none because it creates false confidence
- Sending every low-risk experiment to the committee — teams will route around it into shadow AI
Starting without an inventory
Writing policy without knowing what you govern is rowing in the dark. Step one is a register of every AI system, including bought SaaS tools. Shadow AI usually surfaces in the first count.
Ownerless systems
'The platform team looks after it' means nobody does. Every system needs a named business owner and technical owner; when the owner leaves, reassign it or retire it.
One-off approval
Models get updated, data shifts, usage expands. An approval given at launch may not hold six months later. You need periodic reviews and change-triggered reassessment.
Not a substitute for legal advice
This page is general information. Which obligations apply to a specific system depends on its role, market and intended purpose; ask a lawyer for that.