AI guardrails pro dev tým: praktický framework na jedno odpoledne

Většina dev týmů dnes AI používá — ale bez jakýchkoliv pravidel. Každý vývojář si sám rozhoduje, co do AI pošle, jaký nástroj použije a jak s výstupem naloží. To není adopce — to je chaos.

Guardrails nejsou o omezování. Jsou o tom, dát týmu jasný rámec, ve kterém se mohou pohybovat rychle a bezpečně. Týmy s guardrails mají 3-4x vyšší adopci AI než týmy bez nich. Proč? Protože vývojáři vědí, co můžou dělat, a nebojí se experimentovat.

Guardrails nejsou brzda — jsou akcelerátor. Bez nich se tým bojí experimentovat. S nimi může jet naplno.

Co by měly guardrails pokrývat

1. Klasifikace dat — co smí a nesmí do AI

Tohle je základ. Bez jasné klasifikace vývojáři buď posílají všechno (riziko), nebo nic (ztracená produktivita). Vytvořte jednoduchý cheat sheet a přiložte ho k onboardingu.

# Data klasifikace pro AI nastroje

## ZELENA — muzete poslat do AI
- Verejny kod (open-source, vase vlastni knihovny)
- Genericky boilerplate a sablony
- Chybove hlasky a stacktrace (bez PII)
- Genericke otazky o frameworkech a knihovnach
- Kód, ktery nebyl napsany specificky pro klienta

## CERVENA — nikdy neposilejte do AI
- API klice, connection stringy, secrets
- Produkcni data, PII (jmena, emaily, cisla)
- Klientsky kod bez souhlasu klienta
- Interni bezpecnostni audit a penetracni testy
- Compliance-relevantni dokumenty

## ORANZOVA — jen se schvalenim
- Klientsky kod se souhlasem + enterprise AI plan
- Anonymizovana produkcni data
- Interni architekturní dokumentace

2. Schválené nástroje — jasný seznam

Definujte, které AI nástroje jsou schválené. To neznamená zakázat experimentování — ale zajistit, že citlivá data jdou jen přes schválené kanály s odpovídajícím zabezpečením. Enterprise plány typicky zaručí, že data nejsou použita k trénování modelů.

• Co u schválených nástrojů ověřit:
• Data retention policy — jak dlouho se data uchovávají?
• Používají se data k trénování modelu? (Enterprise plány typicky ne)
• Kde data sídlí? (EU vs US — relevantní pro GDPR)
• Je k dispozici audit log? (kdo poslal co a kdy)
• SSO integrace? (pro enterprise)

3. Review policy pro AI-generovaný kód

AI-generovaný kód by měl projít stejným review procesem jako ručně psaný. Žádné 'AI to napsala, tak to bude OK.' To je nebezpečná iluze. AI generuje kód, který vypadá správně, ale může mít subtilní bugy, které bez review nepojmenujete.

• Review policy pro AI kód:
• AI-generovaný kód = stejný review jako ruční
• Auth, platby, data mutations = vždy lidský review
• Každý PR s AI kódem označen co-authored-by tagem
• Security-kritické části = dvojitý review (AI + člověk + druhý člověk)
• Testy pro AI kód = povinné (AI je napíše, vy zkontrolujete)

4. Transparentnost — vědět, co je od AI

Tým by měl vědět, kdy byl kód generovaný AI. Ne jako stigma — ale jako informaci pro reviewera. Reviewer ví, že se má podívat pozorněji na subtilní logic errors, které AI často dělá.

# Jednoduchy zpusob: Co-authored-by tag v commitu

git commit -m "Add JWT auth middleware

Co-Authored-By: Claude <noreply@anthropic.com>"

# Claude Code tohle dela automaticky
# Cursor/Copilot — pridejte rucne nebo pres hook

Jak to zavést: krok za krokem

Neudělejte z toho 20stránkový dokument. Napište jednu A4 s pravidly — stačí článek, který právě čtete, adaptovaný pro váš kontext.

• Týden 1: Napište jednostránkový dokument s pravidly (data klasifikace, schválené nástroje, review policy)
• Týden 2: Projděte dokument s týmem na standupu — otevřete diskuzi, přijměte feedback
• Týden 3: Publikujte v repo README nebo CLAUDE.md — musí být snadno přístupný
• Týden 4: Přidejte pre-commit hook na detekci secretů (např. gitleaks, detect-secrets)
• Měsíc 2: První retrospektiva — co funguje, co ne, co chybí?

Za měsíc si tým zvykne a pravidla se stanou přirozenou součástí workflow — ne překážkou. Iterujte na základě reálné zkušenosti. Pravidla, která tým nevyužívá nebo obchází, smažte a nahraďte něčím, co funguje.

Časté chyby

• Příliš přísná pravidla — lidé je obcházejí místo dodržování
• Příliš vágní pravidla — nikdo neví, co konkrétně smí
• Žádná enforcement — pravidla existují, ale nikdo je nekontroluje
• Jednorázové zavedení bez iterace — pravidla zastarají za měsíc
• Bez školení — lidé nevědí PROČ pravidla existují

Template ke stažení

Tady je minimální template, který můžete použít jako základ. Adaptujte pro svůj kontext — přidejte specifické nástroje, které používáte, a pravidla specifická pro vaši industrii (zdravotnictví, finance, atd.).

# AI Guardrails — [Nazev firmy]
# Verze: 1.0 | Datum: [dnesni datum]

## Schvalene nastroje
[seznam nastroju s plany]

## Data klasifikace  
ZELENA: [co smi do AI]
CERVENA: [co nesmi do AI]
ORANZOVA: [co potrebuje schvaleni]

## Review policy
- AI kod = standardni review
- Auth/platby/data = vzdy lidsky review
- Co-authored-by tag v commitech

## Kontakt
Otazky: [kdo odpovida]
Aktualizace: [jak casto se reviduje]

Guardrails nejsou jednorázový projekt. Jsou živým dokumentem, který se vyvíjí spolu s týmem a nástroji. Nejdůležitější je začít — a iterovat.