AI Governance for Companies: A Practical Starter Playbook

TL;DR

Someone at your company is already using AI. Developers work with coding assistants, sales has a chat tool drafting emails, product wired an LLM API into the support bot, and someone tried an agent with CRM access last week. The question isn't "will we use AI?" but "who is using what, with which data, at what risk, and do we know about it?"

AI governance is the ability to answer that question routinely: record which AI systems are in use, classify the risk of each, apply rules and controls proportionate to that risk, monitor what happens, and show evidence when asked.

This guide is written for small and mid-sized companies: teams without a full-time compliance function, but that sell into the EU, get security questionnaires from enterprise customers, or process personal data. The setup in one block:

1. Inventory      → Which AI systems exist? (one YAML file or sheet)
2. Classification → What risk class is each one? (decision tree)
3. Policy         → Who may use what, with which data? (1-2 pages)
4. Documentation  → System card, data sheet, decision log
5. Tech controls  → PII redaction, guardrails, human approval, logging, evals, agent permissions
6. Vendors        → Assess LLM API providers against a checklist
7. Monitoring     → Incident log, periodic review, internal audit

Important: This guide is not legal advice. Regulatory details were checked against primary sources (EUR-Lex, the European Commission, KVKK, the Turkish Parliament, NIST, ISO) as of October 2026; sources are listed at the end. The rules move fast and your specific situation needs a lawyer. The goal here is to organize the work engineering and product need to do.

Why now

Three pressures are arriving at once:

1. The regulatory clock is running. The EU AI Act's prohibited practices and AI literacy provisions have applied since February 2025, the general-purpose AI (GPAI) model obligations since August 2025, and the transparency obligations since August 2026. The big block of high-risk rules was postponed, not cancelled. A company outside the EU can still be in scope if its AI system's output is used in the EU.

2. Real incidents keep happening. The publicly reported cases follow the same handful of patterns:

• Employees pasting confidential source code or customer data into a public chat tool.
• A customer-support bot inventing a refund policy that doesn't exist (hallucination) and the company being held to it.
• Instructions hidden in a web page or document steering an agent into leaking data (prompt injection).
• A coding agent with broad permissions deleting files or a database.

None of these is an exotic model failure. They are missing inventory, permissions, approvals and logs.

3. Customers are asking. Enterprise security questionnaires now include "Do you use AI, with which providers, does our data go into training, is there human oversight?" Companies with ready answers close faster; the rest spend weeks in email threads.

The good news: governance for a small company doesn't mean heavy bureaucracy. An inventory file, a two-page policy, a few technical controls and a quarterly review are enough to start.

The regulatory map (October 2026)

This section gives a rough answer to "which rules touch me?" Under each heading, adopted and applicable rules are kept separate from proposed but not adopted ones.

EU AI Act

The EU AI Act (Regulation (EU) 2024/1689) entered into force on 1 August 2024 and applies in stages. It is risk-based:

Annex III areas: biometrics, critical infrastructure, education and vocational training, employment and worker management, access to essential private and public services (including creditworthiness and life and health insurance), law enforcement, migration and border control, administration of justice and democratic processes. An Annex III system may fall outside the high-risk category under Art. 6(3) if it doesn't pose a significant risk of harm to health, safety or fundamental rights, but that assessment has to be documented.

Your role matters. The Act distinguishes the provider, who develops an AI system and places it on the market under its own name, from the deployer, who uses it in its own business. Build a product on an LLM API and sell it under your brand: you are the provider of that product. Use an off-the-shelf tool in internal processes: you're a deployer. Substantially modify a system or repurpose it into a high-risk use, and you can turn from deployer into provider (Art. 25).

Companies outside the EU. The Act applies to providers placing systems on the EU market regardless of where they're established, and to providers and deployers in third countries where the system's output is used in the Union (Art. 2(1)). For a Turkish company selling software into the EU, "we're not in the EU" is not an answer.

GPAI models. Since 2 August 2025, providers of general-purpose models such as LLMs (OpenAI, Anthropic, Google, Mistral and the like) carry obligations on technical documentation, information for downstream providers, a copyright policy and a training-content summary. The Commission's GPAI Code of Practice, published on 10 July 2025, helps with compliance and has three chapters: transparency, copyright, and safety and security. A company that merely uses an API is not a GPAI provider; substantially modifying a model (for example, extensive fine-tuning) can bring provider obligations into play. Check the Commission's GPAI guidelines if that's you.

Timeline after the Digital Omnibus (adopted). Regulation (EU) 2026/1744 ("Digital Omnibus on AI"), amending the AI Act, was adopted on 8 July 2026 and entered into force on 27 July 2026. The current timeline:

The Omnibus also extended some SME relief to "small mid-cap enterprises" (SMCs) and rewrote the AI literacy article: the obligation stays with providers and deployers, with the Commission and Member States now tasked to support them, especially SMEs.

Fines (Art. 99). Up to €35 million or 7% of worldwide annual turnover for prohibited practices; up to €15 million or 3% for most other obligations; up to €7.5 million or 1% for supplying incorrect or misleading information to authorities (whichever is higher in each case). For SMEs, whichever is lower applies. The Commission can fine GPAI providers up to €15 million or 3% (Art. 101).

GDPR

If your AI system processes personal data (offering services to people in the EU or monitoring their behavior), the GDPR already applies, with no special AI carve-out. The articles you'll meet most often:

Fines under Art. 83 come in two tiers: €10 million or 2%, and for the most serious infringements €20 million or 4% (whichever is higher).

Proposed, not adopted. On 19 November 2025 the Commission proposed a broader "Digital Omnibus" (COM(2025) 837) that also amends the GDPR, including provisions clarifying legitimate interest as a legal basis for developing and operating AI. As of October 2026, the European Parliament's legislative tracker shows the file still under negotiation; it is not adopted. Plan against the GDPR in force, not the proposal.

KVKK and Turkey

Turkey has no AI-specific law in force. The framework that applies today is Law No. 6698 on the Protection of Personal Data (KVKK):

• Art. 11(1)(g): Data subjects may object to a result against them arising from analysis of their data exclusively by automated systems. AI-assisted decision processes need a channel that receives these objections and puts a human on them.
• Art. 12(5): In a breach, the controller notifies the data subject and the Board "within the shortest time".
• Art. 9 (transfers abroad): Amended by Law No. 7499; the new regime has applied since 1 June 2024: adequacy decisions, appropriate safeguards (standard contracts, binding corporate rules, written undertakings) and occasional-transfer exceptions. A signed standard contract must be notified to the Authority within five business days. If prompts carry personal data to an LLM API abroad, that is a cross-border transfer.
• Guidance: On 24 November 2025 the KVKK published its "Generative AI and Personal Data Protection Guide (in 15 Questions)". It covers the generative AI lifecycle, its risks and how processing is assessed under Law 6698. It isn't binding, but it shows how the Authority thinks.

Proposed, not adopted. The Artificial Intelligence Law Proposal no. 2/2234, submitted to the Turkish Grand National Assembly on 24 June 2024, is still in committee according to the Assembly's records. There is no enacted AI law; don't build compliance plans on bills.

Practical upshot for a Turkish company selling into the EU: you can be subject to KVKK (data processed in Turkey), the GDPR (data of people in the EU) and the AI Act (systems whose output is used in the EU) all at once. The good news is that the core work (inventory, data map, risk assessment, contracts, logs) overlaps heavily across all three.

US: NIST AI RMF and state laws

The NIST AI RMF 1.0 (NIST AI 100-1) was released on 26 January 2023 and is voluntary. It has four functions: Govern, Map, Measure and Manage. On 26 July 2024 NIST released the Generative AI Profile (NIST AI 600-1), covering risks specific to generative AI. NIST says AI RMF 1.0 is being revised; as of October 2026 no replacement version has been published. It's not binding, but US enterprise customers often base their questionnaires on it, and the steps in this guide roughly follow Govern → Map → Measure → Manage.

At state level, take Colorado as an example. Its comprehensive AI law, SB 24-205, was first delayed to 30 June 2026 and then, before that date arrived, rewritten by SB 26-189, signed on 14 May 2026. The new law requires documentation, consumer notices and a right to meaningful human review for automated decision-making technology used in consequential decisions; its core requirements start on 1 January 2027. US state law is moving fast; if you sell into the US, have a lawyer confirm the current picture.

ISO/IEC 42001

ISO/IEC 42001:2023, published in December 2023, is the first international standard specifying requirements for an AI management system (AIMS). It uses the same management-system structure as ISO/IEC 27001, which makes it the natural extension for companies already certified to 27001. Certification is voluntary. Our advice for a small company: don't aim for the certificate yet, but shape your setup (policy, risk assessment, roles, internal audit, continual improvement) so it lines up with 42001. If an enterprise customer ever asks for certification, you won't start from zero.

Which ones touch me?

Step 1: AI inventory

You can't govern what you can't see. Step one is a system register (AI register) of every AI system in use at the company. It can be a single YAML file in a git repo or a shared spreadsheet; what matters is that it's current and there's only one.

What goes into the inventory:

• Purchased tools: ChatGPT/Claude/Gemini business accounts, coding assistants, meeting note-takers, AI-enabled SaaS (AI modules in your CRM, support desk, HR tools).
• Things you built: features calling an LLM API, RAG systems, agents, classification/scoring models.
• Shadow AI: tools nobody approved but people use anyway. The easiest way to find them is to ask: a short survey, "which AI tools do you use, for what, with which data?" Corporate card spend and the SSO/OAuth app list also help.

A template for each entry:

# ai-register.yaml — one entry per AI system
- id: AI-007
  name: "Support assistant (customer chatbot)"
  owner: "ayse.yilmaz"            # business owner: accountable for the system
  tech_owner: "mehmet.kaya"       # technical owner
  status: production              # idea | pilot | production | retired
  purpose: "Answer order and refund questions on the website"
  users: external                 # internal | external
  affected_people: ["customers"]
  ai_act:
    role: provider                # provider | deployer | both | n/a
    risk_class: limited           # prohibited | high | limited | minimal
    transparency_notice: true     # Art. 50(1): "you are talking to an AI"
  vendor:
    name: "Example LLM Provider"
    model: "model-name-and-version"
    region: "eu"
    dpa_signed: true
    zero_data_retention: false
    trains_on_our_data: false
  data:
    personal_data: true
    categories: ["name", "email", "order id"]
    special_categories: false     # health, biometrics, etc.
    cross_border_transfer: true   # KVKK Art. 9 / GDPR Art. 44+
    legal_basis: "performance of contract"
  controls:
    pii_redaction: true
    guardrails: ["block off-topic", "no refund commitments without approval"]
    human_in_the_loop: "agent approval for refunds above 1000 TRY"
    logging: "prompt+response 90 days, PII masked"
    evals: "weekly 200-question regression set"
  docs:
    system_card: "docs/ai/AI-007-system-card.md"
    dpia: "docs/privacy/DPIA-2026-03.pdf"
  review:
    last_reviewed: 2026-09-15
    next_review: 2026-12-15

Tip: Keeping the inventory next to the code makes it easy to update the entry in the same pull request that adds an AI feature. Adding "Does this change add a new AI system or change the model/data of an existing one?" to the PR template is a good-enough trigger.

Step 2: Intake and risk classification

The inventory shows what exists; new use cases need an intake gate. The point isn't bureaucracy but letting low-risk work through quickly and catching high-risk work early. Anyone with a new AI idea fills in a short form; most are approved within ten minutes.

A simple decision tree for AI risk classification:

Q1. Is it a prohibited practice under AI Act Art. 5?
    (social scoring, manipulation, emotion recognition at work/in education,
     untargeted facial scraping, generating non-consensual intimate material...)
    → YES: STOP. Not allowed.

Q2. Is it in an Annex III area, or in a product under product-safety law?
    (recruitment/worker evaluation, credit, insurance pricing, education,
     critical infrastructure, biometrics, access to essential services...)
    → YES: HIGH-RISK candidate. Legal + DPO review; document the Art. 6(3) assessment.

Q3. Does it make automated decisions about people with significant effects for them?
    → YES: at least HIGH (internal) risk. GDPR Art. 22 / KVKK Art. 11(1)(g) channel, human approval mandatory.

Q4. Does it interact directly with outside people, or generate and publish synthetic content?
    → YES: TRANSPARENCY obligation (Art. 50). "You're talking to an AI" notice, content labels.

Q5. Does it process personal, confidential or customer data? Or is it an agent taking real-world actions?
    → YES: MEDIUM (internal) risk. Data rules, vendor review, logging, agent permissions.

Q6. None of the above (e.g. summarizing public docs, code suggestions, internal drafts)
    → LOW risk. The acceptable-use policy is enough.

The tree deliberately separates the AI Act's legal risk class (prohibited / high / transparency / minimal) from the company's internal risk level. An agent that can read customer data and send email may be "minimal" under the AI Act, but it is certainly not "low" internally.

Controls by risk level:

Step 3: Policies

A long policy goes unread. Aim for a one-page acceptable-use policy + an approved tools list + a data classification table. Together they answer "what am I allowed to do?"

Acceptable use (summary template)

# AI Use Policy (v1.2, October 2026)

1. Use only tools on the "Approved AI Tools" list, with your company account.
   Company data is never processed with personal accounts.
2. Share data according to its classification (table below). If unsure, don't share; ask.
3. You own the AI's output. Check text, code and decisions before they go to a customer.
4. Automated decisions about people (hiring, credit, performance, pricing)
   require approval from the AI governance group.
5. Coding assistants: secrets (.env, keys) are excluded from the agent's reach;
   agent-written code goes through normal code review.
6. Agents: irreversible actions such as writing to production, moving money or
   emailing outsiders never happen without human approval.
7. Need a new AI tool or feature? Fill in the intake form (10 min).
8. Spotted a problem (data leak, strange output, prompt injection)?
   Post in #ai-incidents. Nobody is penalized for reporting.

Data classification and AI

Approved tools list

For each tool keep: name, plan/edition (enterprise or individual), allowed data class, owner, DPA status, last review date. Data retention and training terms often differ between a tool's individual and enterprise plans, so record the plan, not just the product name.

AI literacy

AI Act Art. 4 requires providers and deployers to take measures to ensure sufficient AI literacy among staff working with AI systems; it doesn't require guaranteeing a specific level. In practice: a 30-45 minute session walking through the policy, short role-based training (prompt injection and agent permissions for developers, customer-data rules for sales) and an attendance record. Keep the record; you'll want to show it when a customer or auditor asks.

Step 4: Documentation

Documentation isn't about producing paper. It's about being able to answer three questions later: What does this system do? Why was it designed this way? What happened when something went wrong?

System card

The model card idea lifted to the system level. If you use an LLM via API, the provider writes the model card; what you write is the card for the system you built around the model:

# System Card: AI-007 Support Assistant

## Purpose and scope
- Does: answers order-status and refund questions.
- Doesn't: approve refunds, commit to prices, give legal/medical advice.
- Users: website visitors (TR, EN).

## Architecture
- Model: <provider / model / version>, temperature 0.2
- Knowledge: RAG over published help articles only + order API (read-only)
- Tools: get_order_status(order_id)  ← no write tools

## Known limitations and risks
- Hallucination: may answer beyond policy text → citations required
- Prompt injection: user messages may contain instructions → tools are read-only
- Language: untested outside Turkish and English

## Evaluation
- Regression set: 200 questions, accuracy target ≥ 95%, latest 96.5% (2026-09-28)
- Red team: 2026-08, 14 findings, 13 closed (see RT-2026-08)

## Human oversight
- "Talk to an agent" on every screen; low-confidence answers hand off automatically

## Change log
- 2026-09-01: model version updated, evals re-run

Data sheet

For every dataset you train on, fine-tune with or index for RAG, a short note: source, collection date, whether it contains personal data, legal basis, who can access it, when it gets deleted. RAG indexes are easy to forget: data from someone who asked to be erased can live on in a vector database.

Decision log

Keep important design decisions as short records (the ADR format works well): "Why this provider?", "Why didn't we give the agent permission to send email?", "Why don't we treat this system as high-risk under Art. 6(3)?" The last one matters most: the AI Act expects a provider who decides an Annex III system isn't high-risk to document that assessment.

Step 5: Technical controls

A policy says "don't"; a technical control says "can't". The second is always more reliable. We use the guardrails idea broadly here: every deterministic check you put in front of, behind or around the model.

PII redaction

Mask personal data before it reaches the model and restore it in the response if needed. A simple start:

import re

PATTERNS = {
    "EMAIL": re.compile(r"[\w.+-]+@[\w-]+\.[\w.-]+"),
    "TCKN": re.compile(r"\b[1-9]\d{10}\b"),          # Turkish national ID
    "IBAN": re.compile(r"\bTR\d{2}(?:\s?\d{4}){5}\s?\d{2}\b"),
    "PHONE": re.compile(r"(?:\+90|0)?\s?5\d{2}\s?\d{3}\s?\d{2}\s?\d{2}"),
}

def redact(text: str) -> tuple[str, dict[str, str]]:
    """Replace PII with placeholders; return the mapping to restore it."""
    mapping: dict[str, str] = {}
    for label, pattern in PATTERNS.items():
        for i, match in enumerate(dict.fromkeys(pattern.findall(text))):
            token = f"<{label}_{i}>"
            mapping[token] = match
            text = text.replace(match, token)
    return text, mapping

def restore(text: str, mapping: dict[str, str]) -> str:
    for token, value in mapping.items():
        text = text.replace(token, value)
    return text

masked, m = redact("Ali's email is ali@example.com, phone 0532 123 45 67.")
assert "ali@example.com" not in masked and restore(masked, m).endswith("45 67.")

Regex redaction only catches structured fields (email, national ID, IBAN, phone); it misses names and addresses. For broader needs use an NER-based library such as Microsoft Presidio, and measure what redaction misses in your eval set.

Guardrails

• Input side: filter off-topic or abusive requests, cap input length, flag known prompt-injection patterns (not a sufficient defense on its own).
• Output side: validate structured output against a schema, rule-check forbidden commitments (prices, refund approvals, legal advice), require citations in RAG answers.
• Key principle: the real defense isn't the model "obeying" but the model being limited in what it can do. If a support bot has no write tools, no prompt injection can make it approve a refund.

Human approval

Tune human-in-the-loop controls to risk:

"A human approves" isn't enough on its own; the approver has to see what they're approving and rejecting has to be a real option. A human who rubber-stamps every suggestion isn't a control (automation bias).

Logging

For every AI call record at least: timestamp, user/system identity, system ID (from the inventory), model and version, masked input and output, tools called with arguments, and who approved if there was an approval. Balance retention against data minimization and write it down. For deployers of high-risk systems, the AI Act requires keeping automatically generated logs, to the extent they're under the deployer's control, for at least six months (Art. 26).

{
  "ts": "2026-10-05T09:14:22Z",
  "system_id": "AI-007",
  "actor": "web-session:8f3a",
  "model": "provider/model@2026-09",
  "input_masked": "Where is my order <ORDER_0>?",
  "tool_calls": [{"name": "get_order_status", "args": {"order_id": "<ORDER_0>"}}],
  "output_masked": "Your order has shipped...",
  "guardrail_flags": [],
  "human_approval": null,
  "latency_ms": 1840
}

Evals and red teaming

• Eval set: 50-200 examples per system drawn from real use; measure accuracy, refusal behavior, citations and PII leakage. Re-run whenever the model version, prompt or RAG content changes, including when the provider ships a model update.
• Red teaming: for medium- and high-risk systems, before launch and after significant changes. Scope: prompt injection (direct, and indirect via documents/web content), jailbreaks, system-prompt extraction, tool misuse, data exfiltration, harmful content. Record findings and their closure.

Agent permissions and sandboxing

Agents are the fastest-growing risk area in AI governance, because they produce actions, not just text. Ground rules:

• Least privilege: give the agent only the tools and credentials its task needs. Start read-only; add write permissions one at a time.
• Separate identity: the agent runs under its own service account, not an employee's personal token, so it's distinguishable in logs and revocable in one move.
• Sandbox: run code-executing agents inside an agent sandbox (container, OS sandbox) and restrict network access with a domain allowlist.
• Break the lethal trifecta: if an agent can (1) access private data, (2) read untrusted content and (3) send data out, prompt injection can exfiltrate data. Remove at least one of the three or put it behind approval.
• Limits: turn, budget and time limits; mandatory for unattended (CI, cron) agents.
• Coding assistants: put .env, SSH keys and cloud credentials in deny rules; block dangerous commands with hooks. See the security section of the AI Harness Anatomy guide for details.

Writing "don't share customer data" in a system prompt is a request; the tool never having access to that data is a control. The System Prompt Guide helps with writing prompts, but don't entrust the security boundary to the prompt.

Step 6: Vendor due diligence

The LLM API provider is the most critical stop for your data. Get these questions answered before choosing one, and once a year after. Get the answers in writing from the provider's contract, privacy and trust-center pages; don't rely on what was said on a sales call.

Watch out: a provider's consumer app, enterprise plan and API usually have different data terms. Assess the plan and endpoint you'll actually use. Models accessed through cloud platforms (AWS, Azure, Google Cloud) may also come with terms that differ from the model maker's own.

Step 7: Monitoring, incidents, audits

Monitoring

A deployed AI system isn't static: model versions change, users ask unexpected things, RAG content goes stale. A handful of metrics per system is enough:

• Quality: eval score trend, thumbs-up/down ratio, hand-off-to-human rate.
• Safety: guardrail trigger counts, PII redaction misses, denied tool calls.
• Cost and usage: token consumption, request volume, error rate.

Incident management

Define "AI incident" up front, or nobody will know what to report. Examples: personal or confidential data reaching an unauthorized model/person, wrong and harmful information given to a customer, an agent taking an unauthorized action, a successful prompt injection, a discriminatory output.

1. Detect and report  → #ai-incidents channel, on-call person
2. Contain            → switch off the feature (feature flag), revoke the agent's credentials
3. Assess             → personal data breach? (GDPR Art. 33: 72 hours; KVKK Art. 12(5): shortest time)
4. Fix                → root cause, add a control, add a regression example to the eval set
5. Record and learn   → incident record, update inventory and system card

After every incident add at least one new test to the eval set. It's the cheapest way to stop the same failure from quietly coming back.

Audits

An AI audit at a small company doesn't need an outside auditor; start with a quarterly internal review:

• Is the inventory current? Was a shadow-AI sweep done?
• Does every medium/high-risk system have a current system card, eval result and owner?
• Have vendor terms changed (retention, training, subprocessors)?
• Are incidents closed and their actions implemented?
• Is a regulatory date coming up (e.g. 2 December 2027)?

Once a year, especially if enterprise customers ask, an independent pair of eyes (an outside consultant or an ISO/IEC 42001 pre-assessment) is worth it.

Roles and RACI

At a small company most of these roles sit with the same few people; what matters is that every task has exactly one accountable owner. Suggested structure: a small AI governance group chaired by the CTO or engineering lead, with product, security, legal/DPO and one business representative, meeting for 30 minutes a month.

R = responsible, A = accountable (one person), C = consulted, I = informed

30/60/90-day plan

Days 1-30: visibility

• Name the AI governance group and a single accountable (A) person.
• Run a shadow-AI survey; scan spend and the SSO app list.
• Create ai-register.yaml and record every known system.
• Publish the one-page acceptable-use policy and the approved tools list.
• Stop confidential data going into public tools; move to an enterprise plan or approved API.
• Open the #ai-incidents channel.

Days 31-60: control

• Classify every system with the decision tree; take prohibited or high-risk candidates to legal.
• Write system cards for medium- and high-risk systems.
• Complete the vendor checklist for your main LLM providers; finalize the DPA and transfer basis (GDPR SCCs / KVKK standard contract).
• Add the Art. 50 notice ("you're talking to an AI") to external-facing bots.
• Roll out PII redaction and central logging.
• Review agent permissions: separate service accounts, read-only by default, approval for irreversible actions.
• Hold the AI literacy session and record attendance.

Days 61-90: continuity

• Build an eval set for every medium/high-risk system and wire it into CI.
• Run the first red-team exercise on the riskiest system.
• Complete DPIAs where needed.
• Write the incident response procedure and run a tabletop exercise.
• Add the AI inventory question to the PR template; launch the intake form.
• Schedule the first quarterly review; put the regulatory dates (2 December 2026, 2 December 2027) on the agenda.

Checklist

Inventory and classification

• Is every AI system at the company in the inventory, each with a business owner?
• Has each system's AI Act role (provider/deployer) and risk class been determined?
• Does any use touch an Annex III area (hiring, credit, insurance, education...), and has legal reviewed it?

Policy and people

• Is the acceptable-use policy one page long, and does everyone know it?
• Is the approved tools list kept at plan level (enterprise/individual)?
• Has AI literacy training happened, with a record kept?

Data and vendors

• Are DPAs signed with LLM providers, and are training and retention terms confirmed in writing?
• Is the GDPR and KVKK basis for cross-border transfers in place (including the KVKK standard-contract notification)?
• Are personal data in RAG indexes updated when erasure requests come in?

Technical controls

• Are PII redaction and central logging live?
• Do external-facing AI systems show an AI notice?
• Do agents run with their own identity, least privilege, in a sandbox, with limits?
• Are irreversible actions and significant decisions about people gated by human approval?
• Do eval sets run automatically on model/prompt changes?

Monitoring and audit

• Is "AI incident" defined, with a reporting channel and an owner?
• Is the quarterly review on the calendar?
• When a customer says "tell us about your AI governance", do you have a pack you can send within an hour?

Further reading

Primary sources (checked as of October 2026)

• Regulation (EU) 2024/1689 (AI Act), EUR-Lex
• Regulation (EU) 2026/1744 (Digital Omnibus on AI), EUR-Lex
• European Commission: GPAI Code of Practice
• European Parliament Legislative Train: Digital Omnibus (GDPR proposal)
• GDPR text (gdpr-info.eu)
• KVKK: Transfers abroad
• KVKK: Generative AI and Personal Data Protection Guide (in 15 Questions)
• Turkish Grand National Assembly: AI Law Proposal 2/2234
• NIST AI Risk Management Framework
• ISO/IEC 42001:2023
• Colorado SB 26-189

On this site

• AI Governance, EU AI Act, AI Risk Classification: concepts and the legal frame.
• NIST AI RMF, ISO/IEC 42001, AI Audit: frameworks and auditing.
• Model Card, AI and Data Privacy: documentation and data.
• Guardrails, Human-in-the-loop, Agent Sandbox, Prompt Injection, Hallucination: technical controls and risks.
• AI Harness Anatomy and System Prompt Guide: the internals of agents and prompts.