AIFC-022: AI-NDA Boundary

Status: Draft 0.1 Standard: AI-First Community Standard Zkráceně: AIFC Navazuje na:

• AIFC-000 Manifest AI-first komunity
• AIFC-001 Core Concepts
• AIFC-010 Knowledge Structure
• AIFC-011 Operational DNA
• AIFC-020 Human-Managed AI
• AIFC-021 AI as External Expert Capacity

Účel dokumentu: Definovat AI-NDA Boundary jako hranici důvěrnosti pro použití AI nad neveřejným know-how komunity. Popsat, jaká data AI smí vidět, za jakým účelem, kde se zpracovávají, zda se ukládají, zda mohou být použita pro trénink, kdo vidí prompty a výstupy, jak se auditují přístupy, jak se řeší incidenty a jak se zabraňuje tomu, aby se AI stala nekontrolovanou externí pamětí komunity.

1. Purpose of this document

Tento dokument definuje AI-NDA Boundary.

AIFC chápe AI jako externí expertní kapacitu. Pokud má AI pracovat s neveřejným know-how komunity, musí mít hranici důvěrnosti podobnou tomu, co by komunita řešila při zapojení externí konzultační firmy.

Externí konzultant nedostane automaticky přístup ke všemu.

Stejně tak AI nesmí automaticky vidět vše, co komunita ví.

AI-NDA Boundary určuje:

• jaká data AI smí vidět,
• jaká data AI nesmí vidět,
• za jakým účelem je smí použít,
• kde se data zpracovávají,
• zda se ukládají,
• zda mohou být použita pro trénink,
• kdo vidí prompty,
• kdo vidí výstupy,
• jak se loguje přístup,
• jak se odvolává přístup,
• jak se řeší incident,
• jak se chrání Operational DNA,
• jak se brání AI lock-inu,
• a jak se zajišťuje, že AI není nekontrolovaná externí paměť komunity.

2. Core principle

Základní princip tohoto dokumentu je:

No non-public community knowledge may be processed by AI without a defined confidentiality boundary.

Česky:

Žádné neveřejné know-how komunity nesmí být zpracováno AI bez definované hranice důvěrnosti.

AIFC říká:

No AI access without an AI-NDA Boundary.

Česky:

Žádný AI přístup bez AI-NDA Boundary.

Tento princip neznamená, že AI nemá být používána.

Znamená, že AI má být používána vědomě, bezpečně a v rozsahu, který komunita chápe a vlastní.

3. Definition

AI-NDA Boundary je pravidly definovaná hranice důvěrnosti pro použití AI nad neveřejným know-how, daty, dokumenty, rozhodnutími, workflow, skills nebo Operational DNA komunity.

Není to jen právní dokument.

Je to kombinace:

• governance pravidel,
• datové klasifikace,
• technických omezení,
• přístupových práv,
• auditních pravidel,
• vendor pravidel,
• pravidel pro trénink a ukládání,
• pravidel pro výstupy,
• incident response,
• a exit strategie.

AI-NDA Boundary odpovídá na otázku:

Za jakých podmínek smí externí inteligence pracovat s know-how komunity?

4. Why AI-NDA Boundary matters

AI může být velmi užitečná právě tehdy, když rozumí kontextu komunity.

Ale čím více kontextu AI dostane, tím větší vzniká riziko.

Rizika zahrnují:

• únik citlivých dat,
• předání Operational DNA externímu vendorovi,
• použití dat pro trénink,
• ukládání promptů mimo kontrolu komunity,
• neviditelný přístup administrátorů nebo třetích stran,
• vznik externí agentické paměti,
• ztrátu kontroly nad know-how,
• AI lock-in,
• právní nebo compliance riziko,
• reputační riziko,
• ghost AI company reuse,
• ztrátu důvěry mezi komunitami.

Největší riziko nevzniká jen tím, že data uniknou.

Vzniká i tím, že komunita postupně přesune své myšlení, rozhodovací logiku a provozní know-how do externího systému, aniž by si toho všimla.

Minimum requirement

Každé významné AI použití nad neveřejnou knowledge base musí mít definovanou AI-NDA Boundary.

5. AI-NDA is not optional for non-public knowledge

Veřejný obsah může být zpracováván AI s nižšími nároky.

Neveřejný obsah vyžaduje hranici.

Neveřejný obsah zahrnuje například:

• interní dokumentaci,
• zákaznické informace,
• interní procesy,
• rozhodovací logiku,
• security pravidla,
• finanční informace,
• interní strategii,
• skills,
• AI skills,
• agentické workflow,
• knowledge base,
• Operational DNA,
• neveřejné decision records,
• interní feedback,
• incidenty,
• zranitelnosti,
• obchodní know-how.

Minimum requirement

Komunita musí definovat, které kategorie obsahu mohou být zpracovány AI bez schválení a které vyžadují AI-NDA Boundary.

6. Data classification

AI-NDA Boundary musí vycházet z datové klasifikace.

AIFC doporučuje minimální klasifikaci:

Public
Internal
Restricted
Operational DNA

Public

Obsah určený k veřejnému sdílení.

Příklady:

• veřejný web,
• veřejný manifest,
• veřejné marketingové texty,
• veřejné produktové informace.

AI access může být obecně povolen, pokud výstup nepředstírá schválenou komunikaci komunity bez review.

Internal

Obsah určený pro členy komunity.

Příklady:

• interní návody,
• běžné interní dokumenty,
• onboarding,
• interní workflow bez citlivých detailů.

AI access může být povolen v rámci schválených nástrojů a účelu.

Restricted

Citlivý obsah s omezeným přístupem.

Příklady:

• zákaznická data,
• osobní údaje,
• bezpečnostní informace,
• finanční detaily,
• neveřejná strategie,
• incidenty,
• právní nebo HR informace.

AI access vyžaduje explicitní hranici, schválení a audit.

Operational DNA

Kritické know-how popisující, jak komunita skutečně funguje.

Příklady:

• rozhodovací logika,
• kritické workflow,
• business model,
• AI agentické workflow,
• fallbacky,
• konkurenční know-how,
• human skills,
• AI skills,
• governance pravidla.

AI access musí být nejpřísněji řízený.

Minimum requirement

AI-NDA Boundary musí explicitně říkat, jaké úrovně citlivosti jsou povolené, omezené nebo zakázané.

7. Purpose limitation

AI nesmí používat data obecně.

AI smí používat data pouze pro schválený účel.

Špatně:

AI may use internal documentation.

Lépe:

AI may use selected internal documentation only to identify outdated, duplicated and ownerless content and create maintenance change proposals.

Purpose limitation chrání komunitu před tím, aby se z úzkého AI engagementu stal nekontrolovaný přístup do know-how.

Minimum requirement

Každá AI-NDA Boundary musí obsahovat schválený účel zpracování.

8. Allowed data

AI-NDA Boundary musí definovat povolená data.

Příklad:

Allowed data:
- selected internal process documents,
- approved public pages,
- active workflow descriptions,
- non-restricted decision records,
- anonymized support patterns.

Povolená data musí být co nejkonkrétnější.

Čím citlivější AI engagement, tím přesnější musí být seznam povolených dat.

Minimum requirement

AI-NDA Boundary musí definovat allowed data nebo allowed knowledge domains.

9. Forbidden data

AI-NDA Boundary musí definovat zakázaná data.

Příklad:

Forbidden data:
- personal customer data,
- raw HR records,
- credentials,
- secrets,
- security vulnerabilities,
- restricted financial data,
- unapproved Operational DNA,
- legal privileged material.

Zakázaná data musí být chráněna nejen pravidlem, ale podle možností také technicky.

Například:

• access control,
• redaction,
• data loss prevention,
• secrets scanning,
• prompt filtering,
• restricted connectors,
• sandboxing.

Minimum requirement

AI-NDA Boundary musí definovat forbidden data.

10. Need-to-know principle

AI má dostat pouze data, která potřebuje k danému účelu.

Ne všechna data, která by mohla být užitečná.

Need-to-know princip platí pro lidi, externí konzultanty i AI.

Příklady:

• AI pro návrh veřejného FAQ nepotřebuje interní incident reporty.
• AI pro cleanup dokumentace nepotřebuje osobní údaje zákazníků.
• AI pro návrh sprint summary nepotřebuje security secrets.
• AI pro UX copy nepotřebuje business model Operational DNA.

Minimum requirement

AI-NDA Boundary musí uplatňovat need-to-know a least privilege princip.

11. Processing location

AI-NDA Boundary musí definovat, kde se data zpracovávají.

Možnosti mohou zahrnovat:

• lokální model,
• private cloud,
• enterprise AI tenant,
• veřejný AI nástroj,
• vendor-hosted prostředí,
• regionálně omezené zpracování,
• on-premise infrastruktura.

Processing location je důležitá pro:

• právo,
• compliance,
• audit,
• data residency,
• důvěrnost,
• incident response,
• vendor risk.

Minimum requirement

AI-NDA Boundary pro restricted data nebo Operational DNA musí definovat processing location nebo povolený typ prostředí.

12. Storage and retention

AI-NDA Boundary musí definovat, zda se data, prompty a výstupy ukládají.

Musí odpovědět na otázky:

• ukládají se prompty?
• ukládají se výstupy?
• ukládají se embeddings?
• ukládá se agent memory?
• jak dlouho?
• kdo má přístup?
• lze data smazat?
• existuje retention policy?
• jak se řeší auditní logy?
• co se stane po ukončení AI engagementu?

Minimum requirement

AI-NDA Boundary musí definovat storage and retention pravidla.

13. Training use

Jedna z nejdůležitějších otázek:

Mohou být data komunity použita pro trénink nebo zlepšování modelu?

Pro neveřejná data by výchozí odpověď měla být:

No training use unless explicitly approved.

Česky:

Žádné použití pro trénink, pokud není výslovně schváleno.

To zahrnuje:

• model training,
• fine-tuning,
• reinforcement learning,
• vendor improvement,
• dataset creation,
• persistent memory training,
• anonymized reuse, pokud není dostatečně schválené.

Minimum requirement

AI-NDA Boundary musí explicitně říkat, zda smí být data použita pro trénink nebo zlepšování modelu.

14. Prompt and output visibility

Komunita musí vědět, kdo může vidět prompty a výstupy.

To zahrnuje:

• členy komunity,
• administrátory nástroje,
• AI vendora,
• subdodavatele,
• support vendora,
• auditní role,
• bezpečnostní tým,
• jiné komunity.

Prompty mohou obsahovat citlivější informace než finální výstupy.

Výstupy mohou zase obsahovat odvozené know-how, které je citlivé, i když vstupní data byla méně citlivá.

Minimum requirement

AI-NDA Boundary musí definovat visibility pravidla pro prompty, výstupy, logy a agent memory.

15. Derived knowledge

AI může vytvořit odvozené know-how.

Například:

• shrnutí strategie,
• syntézu zákaznických potřeb,
• mapu slabin,
• návrh business modelu,
• security risk report,
• optimalizované workflow,
• AI skill,
• decision logic,
• Operational DNA extraction.

Derived knowledge může být citlivější než jednotlivé vstupy.

AI-NDA Boundary proto musí chránit nejen vstupní data, ale i výstupy.

Minimum requirement

AI outputs vytvořené z restricted dat nebo Operational DNA musí zdědit odpovídající citlivost, dokud nejsou explicitně překlasifikovány.

16. Agent memory

Agent memory je zvláštní riziko.

Pokud si AI agent ukládá informace napříč interakcemi, může se stát externí pamětí komunity.

To může být užitečné, ale také nebezpečné.

Agent memory musí mít jasná pravidla:

• co se smí uložit,
• co se nesmí uložit,
• kdo to vidí,
• jak se to maže,
• jak se exportuje,
• jak se audituje,
• jak se brání uložení Operational DNA mimo source of truth,
• jak se řeší vendor exit.

Minimum requirement

Agent memory nesmí obsahovat restricted data nebo Operational DNA bez explicitního schválení, auditu a exit mechanismu.

17. Source of truth protection

AI-NDA Boundary musí chránit source of truth.

AI může source of truth číst nebo navrhovat změny pouze podle role a oprávnění.

AI nesmí:

• změnit active pravidlo bez schválení,
• přepsat decision record,
• smazat kritické know-how,
• překlasifikovat sensitivity bez governance,
• uložit AI-generated interpretaci jako approved truth,
• přesunout know-how mimo source of truth.

Minimum requirement

AI write access do source of truth musí být oddělen od AI read access a musí mít samostatné approval rules.

18. Operational DNA protection

Operational DNA je nejcitlivější knowledge layer.

AI přístup k Operational DNA vyžaduje vyšší úroveň ochrany.

AI-NDA Boundary pro Operational DNA musí definovat:

• proč je přístup nutný,
• jaký je přesný scope,
• jaké části DNA jsou povolené,
• jaké části jsou zakázané,
• zda je nutná anonymizace nebo redakce,
• jak se loguje použití,
• kdo schvaluje výstupy,
• jak se řeší derived knowledge,
• jak se provádí export,
• jak se řeší incident,
• jaká je exit strategie.

Minimum requirement

AI přístup k Operational DNA musí být explicitně schválený, omezený, auditovatelný a odvolatelný.

19. Redaction and minimization

Před předáním dat AI má komunita zvážit redakci a minimalizaci.

Redaction znamená odstranění citlivých částí.

Minimization znamená předat pouze nezbytné informace.

Příklady:

• nahradit jména zákazníků anonymními identifikátory,
• odstranit osobní údaje,
• zobecnit finanční čísla,
• odstranit secrets,
• vynechat konkrétní bezpečnostní zranitelnosti,
• použít syntetická data,
• poskytnout pouze relevantní výřez knowledge base.

Minimum requirement

U restricted dat a Operational DNA musí být posouzena možnost redakce nebo minimalizace před AI zpracováním.

20. Human approval

AI-NDA Boundary musí říkat, kdo schvaluje AI přístup k datům.

Schvalování může zahrnovat:

• data owner,
• security owner,
• AI governance owner,
• legal owner,
• process owner,
• community owner,
• Operational DNA owner.

Čím vyšší citlivost, tím vyšší rozhodovací úroveň.

Minimum requirement

AI přístup k restricted datům nebo Operational DNA musí mít dohledatelné schválení.

21. Auditability

AI-NDA Boundary musí být auditovatelná.

Auditní stopa může obsahovat:

• kdo schválil AI přístup,
• jaký byl účel,
• jaká data byla použita,
• jaký nástroj nebo model byl použit,
• kdy se zpracování stalo,
• jaké výstupy vznikly,
• kdo výstupy viděl,
• co bylo zapsáno do source of truth,
• zda vznikl incident,
• kdy byl přístup ukončen.

Audit nesmí být pouze formální.

Musí umožnit komunitě zjistit, co se s jejím know-how stalo.

Minimum requirement

AI zpracování restricted dat nebo Operational DNA musí mít auditní stopu.

22. Revocation

AI přístup musí být odvolatelný.

Komunita musí umět:

• vypnout AI agentovi přístup,
• zrušit connector,
• odstranit oprávnění,
• smazat nebo uzamknout agent memory,
• ukončit engagement,
• přepnout do AI-off režimu,
• zablokovat export,
• označit výstupy jako compromised.

Minimum requirement

AI-NDA Boundary musí definovat mechanismus odvolání přístupu.

23. Incident response

AI-NDA Boundary musí obsahovat incident response.

Incident může být například:

• AI zpracovala zakázaná data,
• restricted data byla vložena do neschváleného nástroje,
• Operational DNA byla zpřístupněna mimo boundary,
• vendor uložil data neočekávaně,
• AI výstup obsahoval citlivé údaje,
• agent memory obsahuje zakázané informace,
• AI nástroj byl kompromitován,
• výstup byl publikován bez schválení.

Incident response musí řešit:

• detekci,
• zastavení zpracování,
• odvolání přístupu,
• analýzu rozsahu,
• oznámení ownerům,
• právní nebo compliance kroky,
• cleanup agent memory,
• označení compromised artefaktů,
• lessons learned,
• update AI-NDA Boundary.

Minimum requirement

Komunita musí mít incident response pro porušení AI-NDA Boundary.

24. AI-NDA Boundary lifecycle

AI-NDA Boundary má lifecycle.

Doporučené stavy:

draft
proposed
under_review
approved
active
paused
deprecated
revoked
archived
compromised

Why it matters

Boundary se může měnit podle:

• změny vendora,
• změny modelu,
• změny dat,
• změny účelu,
• incidentu,
• nového právního požadavku,
• změny sensitivity,
• změny AI operating mode.

Minimum requirement

Každá AI-NDA Boundary musí mít status, ownera a review mechanismus.

25. Relationship with AI engagement

AI-NDA Boundary není totéž jako AI engagement.

AI engagement:
Proč a k čemu AI používáme.

AI-NDA Boundary:
Co AI smí vidět a za jakých podmínek.

Jeden AI engagement může odkazovat na jednu nebo více AI-NDA Boundaries.

Jedna AI-NDA Boundary může být použita více engagementy, pokud mají stejný účel, data a pravidla.

Minimum requirement

AI engagement nad neveřejnými daty musí odkazovat na schválenou AI-NDA Boundary.

26. Relationship with Human Cockpit Layer

Human Cockpit Layer musí zobrazovat AI-NDA Boundary lidsky srozumitelně.

Člen komunity by měl vidět:

• zda dané AI použití pracuje s public, internal, restricted nebo Operational DNA daty,
• jaký je účel,
• kdo je owner,
• jaký nástroj nebo model se používá,
• zda je trénink zakázán,
• jak dlouho se data ukládají,
• co čeká na schválení,
• zda došlo k incidentu,
• kdy je další review.

Human Cockpit Layer nemá zobrazovat citlivý detail každému.

Má zobrazovat odpovídající pohled podle role.

Minimum requirement

Významné AI-NDA Boundaries musí být lidsky viditelné odpovědným rolím.

27. Relationship with AI-off fallback

AI-NDA Boundary musí počítat s možností, že AI přístup bude omezen nebo vypnut.

Pokud je boundary pozastavena, revoked nebo compromised, komunita musí vědět:

• které workflow se zastaví,
• jaký fallback se aktivuje,
• kdo je informován,
• jak se dokončí rozpracovaná práce,
• jak se chrání výstupy,
• jak se obnoví provoz bez daného AI nástroje.

Minimum requirement

Kritické AI workflow závislé na AI-NDA Boundary musí mít fallback pro případ pozastavení nebo odvolání boundary.

28. Suggested metadata

Příklad metadat pro AI-NDA Boundary:

ai_nda_boundary:
  id:
  title:
  status: draft | proposed | under_review | approved | active | paused | deprecated | revoked | archived | compromised
  owner:
  approved_by:
  purpose:
  allowed_data:
  forbidden_data:
  data_classification_allowed:
    - public
    - internal
    - restricted
    - operational_dna
  ai_tools_or_models:
  processing_location:
  storage_policy:
  retention_policy:
  training_use: forbidden | allowed_with_approval | allowed
  prompt_visibility:
  output_visibility:
  agent_memory_allowed: true | false
  derived_knowledge_classification:
  redaction_required: true | false
  audit_required: true | false
  revocation_mechanism:
  incident_response:
  related_ai_engagements:
  related_workflows:
  related_operational_dna:
  review_cycle:
  last_reviewed:

Tato struktura je ilustrativní.

Finální schéma má být definováno v agent-actionable vrstvě standardu.

29. Boundary levels

AIFC může používat úrovně AI-NDA Boundary.

Level 0 — Public AI Use

AI pracuje pouze s veřejnými daty.

Požadavky:

• základní review výstupů,
• žádná neveřejná data,
• žádná Operational DNA.

Level 1 — Internal AI Use

AI pracuje s běžnými interními daty.

Požadavky:

• schválený nástroj,
• purpose limitation,
• základní audit,
• owner.

Level 2 — Restricted AI Use

AI pracuje s restricted daty.

Požadavky:

• explicitní approval,
• AI-NDA Boundary,
• audit,
• storage and retention pravidla,
• training use zakázán, pokud není schválen,
• redaction/minimization posouzení.

Level 3 — Operational DNA AI Use

AI pracuje s Operational DNA.

Požadavky:

• explicitní vyšší schválení,
• přísný scope,
• audit,
• agent memory kontrola,
• derived knowledge ochrana,
• exit strategy,
• incident response,
• fallback,
• pravidelné review.

Minimum requirement

Komunita musí rozlišovat alespoň public, internal, restricted a Operational DNA AI use.

30. Anti-patterns

AIFC odmítá následující anti-patterny.

30.1 AI access by convenience

AI dostane data, protože je to rychlé, ne protože je to schválené.

30.2 No distinction between public and internal

Komunita nerozlišuje, zda AI pracuje s veřejným nebo neveřejným obsahem.

30.3 No training rule

Není jasné, zda vendor smí data použít pro trénink nebo zlepšování modelu.

30.4 Prompt leakage ignored

Komunita řeší výstupy, ale ignoruje, že prompty obsahují citlivá data.

30.5 Derived knowledge unclassified

AI vytvoří citlivou syntézu a ta je považována za méně citlivou než vstupy.

30.6 Agent memory as uncontrolled storage

Agent si ukládá neveřejné know-how mimo source of truth a bez auditovatelnosti.

30.7 Operational DNA sent to AI without explicit approval

Kritické provozní know-how je vloženo do AI nástroje bez boundary.

30.8 AI-NDA Boundary without owner

Boundary existuje, ale nikdo ji nevlastní a nereviduje.

30.9 AI-NDA Boundary without revocation

AI přístup nelze rychle vypnout.

30.10 AI-NDA Boundary without incident response

Komunita neví, co dělat při porušení boundary.

31. Minimal requirements

AIFC komunita musí v oblasti AI-NDA Boundary minimálně splnit:

1. Rozlišuje veřejná, interní, restricted a Operational DNA data.
2. Neveřejná data nejsou zpracována AI bez definované hranice důvěrnosti.
3. AI-NDA Boundary má ownera.
4. AI-NDA Boundary má status.
5. AI-NDA Boundary má schválený účel.
6. AI-NDA Boundary definuje allowed data.
7. AI-NDA Boundary definuje forbidden data.
8. AI-NDA Boundary uplatňuje need-to-know a least privilege princip.
9. Restricted nebo Operational DNA use definuje processing location nebo povolený typ prostředí.
10. AI-NDA Boundary definuje storage and retention pravidla.
11. AI-NDA Boundary explicitně definuje training use.
12. AI-NDA Boundary definuje prompt and output visibility.
13. Derived knowledge dědí citlivost vstupů, dokud není překlasifikováno.
14. Agent memory je řízená, nebo zakázaná.
15. AI write access do source of truth má samostatná approval pravidla.
16. AI přístup k Operational DNA je explicitně schválený a auditovatelný.
17. Restricted data a Operational DNA vyžadují redaction/minimization posouzení.
18. AI access je odvolatelný.
19. Existuje incident response pro porušení boundary.
20. AI-NDA Boundary je navázaná na relevantní AI engagementy.
21. Kritické AI workflow má fallback při pozastavení nebo odvolání boundary.
22. Human Cockpit Layer zviditelňuje boundary odpovědným rolím.

32. Summary

AI-NDA Boundary je hranice důvěrnosti pro externí inteligenci.

AI může komunitě pomoci právě proto, že dokáže pracovat s kontextem.

Ale kontext komunity je cenný.

Někdy je to běžné interní know-how. Někdy restricted data. Někdy Operational DNA. Někdy samotná schopnost komunity fungovat.

AIFC proto říká:

Do not give AI access to community knowledge without purpose, boundary, ownership and audit.

Česky:

Nedávejte AI přístup ke know-how komunity bez účelu, hranice, vlastnictví a auditu.

AI nemá být nekontrolovaná externí paměť komunity.

AI má být řízená externí expertní kapacita, která pracuje pouze v hranicích, které komunita chápe, schválila a dokáže odvolat.

AI-NDA Boundary turns AI access into governed trust.

AIFC-023: AI as Team Member

Status: Draft 0.1 Standard: AI-First Community Standard Zkráceně: AIFC Navazuje na:

• AIFC-000 Manifest AI-first komunity
• AIFC-001 Core Concepts
• AIFC-002 Community Model
• AIFC-010 Knowledge Structure
• AIFC-011 Operational DNA
• AIFC-020 Human-Managed AI
• AIFC-021 AI as External Expert Capacity
• AIFC-022 AI-NDA Boundary

Účel dokumentu: Definovat princip AI as Team Member: jak může být AI agent zapojen jako řízený člen týmu s rolí, scope, oprávněními, limity, human ownerem, auditovatelností, měřením hodnoty, pravidly schvalování, fallbackem a možností vypnutí.

1. Purpose of this document

Tento dokument popisuje, jak může AIFC komunita zapojit AI agenta jako člena týmu.

AI agent není člověk.

Nemá lidskou odpovědnost, vlastní hodnotový úsudek, sociální zakotvení ani skutečné členství v komunitě.

Může však vykonávat opakované role podobné týmovým rolím:

• analyzovat,
• sumarizovat,
• navrhovat,
• kontrolovat,
• upozorňovat,
• připravovat dokumenty,
• vytvářet change proposals,
• validovat strukturu,
• udržovat knowledge base,
• pomáhat s backlogem,
• podporovat rozhodování,
• vykonávat schválené nízkorizikové kroky.

AIFC proto umožňuje chápat AI agenta jako řízeného člena týmu, ale pouze za podmínky, že má jasně definované hranice a že odpovědnost zůstává lidem nebo komunitě.

2. Core principle

Základní princip tohoto dokumentu je:

AI may act as a team member only when its role, scope, permissions, owner and limits are explicit.

Česky:

AI může působit jako člen týmu pouze tehdy, když má explicitně definovanou roli, scope, oprávnění, ownera a limity.

AI agent může být užitečný týmový spolupracovník.

Nesmí však být neviditelný, neomezený nebo neodpovědný aktér uvnitř komunity.

AIFC proto říká:

No AI team member without role, owner, boundary and audit.

Česky:

Žádný AI člen týmu bez role, ownera, hranice a auditu.

3. Definition

AI as Team Member je řízený způsob zapojení AI agenta do práce komunity.

AI team member má:

• roli,
• účel,
• scope,
• human nebo community ownera,
• povolené vstupy,
• povolené akce,
• zakázané akce,
• přístupová oprávnění,
• AI-NDA Boundary,
• pravidla schvalování,
• auditní stopu,
• měření přínosu,
• fallback,
• exit nebo vypnutí.

AI team member není autonomní člen komunity ve smyslu lidské odpovědnosti.

Je to řízená pracovní kapacita.

4. Why this concept matters

AI se často používá neformálně:

• někdo otevře chat,
• vloží data,
• požádá o návrh,
• zkopíruje výstup,
• rozhodnutí se posune dál,
• ale nikde není jasné, kdo AI použil, proč, s jakým oprávněním a jaký byl dopad.

To je nebezpečné, pokud AI začne opakovaně ovlivňovat práci týmu.

Pokud AI plní opakovanou roli, musí být řízena jako role.

Stejně jako člověk v týmu nemá neomezený přístup a neomezenou rozhodovací pravomoc, ani AI agent nesmí mít neomezené možnosti jen proto, že je užitečný.

Minimum requirement

Pokud AI agent vykonává opakovanou nebo významnou týmovou roli, musí být definován jako AI team member s rolí, ownerem a pravidly.

5. AI team member vs AI tool

AIFC rozlišuje běžný AI tool a AI team member.

AI tool

AI tool je použit ad hoc pro konkrétní úkol.

Příklady:

• jednorázové shrnutí veřejného textu,
• návrh formulace e-mailu,
• překlad veřejného textu,
• jednoduchá brainstorm pomoc.

AI team member

AI team member má opakovanou roli v komunitě.

Příklady:

• Knowledge Maintenance Agent,
• Backlog Refinement Agent,
• Security Review Assistant,
• UX Review Agent,
• AI Retrospective Agent,
• Change Proposal Analyst,
• Documentation Cleanup Agent,
• Support Triage Agent,
• Code Review Assistant,
• Community Interface Monitor.

Minimum requirement

Pokud AI opakovaně vykonává definovaný typ práce, má být převedena z ad hoc tool použití do řízeného AI team member modelu.

6. Role definition

Každý AI team member musí mít jasně definovanou roli.

Role má odpovídat na otázky:

• Proč agent existuje?
• Jakému záměru slouží?
• Jakou práci vykonává?
• Jaký typ výstupů vytváří?
• Komu pomáhá?
• Jaký problém řeší?
• Jaké hodnoty musí respektovat?
• Jaké hranice nesmí překročit?

Příklad:

Role:
Knowledge Maintenance Agent

Purpose:
Help the community detect outdated, duplicated, ownerless or structurally invalid knowledge artefacts and create maintenance proposals.

Not responsible for:
Approving changes, deleting active knowledge, changing sensitivity or updating Operational DNA without review.

Minimum requirement

AI team member musí mít roli zapsanou v source of truth.

7. Human owner

Každý AI team member musí mít human nebo community ownera.

Owner odpovídá za:

• účel agenta,
• scope,
• oprávnění,
• AI-NDA Boundary,
• výstupy,
• review,
• měření hodnoty,
• náklady,
• rizika,
• vypnutí,
• změnu role,
• aktualizaci agent skillu,
• řešení incidentu.

AI agent nesmí být ownerem sám sobě.

Minimum requirement

AI team member bez ownera není AIFC kompatibilní.

8. Scope

Scope definuje, kde a jak smí AI team member pracovat.

Může zahrnovat:

• knowledge domains,
• projekty,
• týmy,
• typy dokumentů,
• typy dat,
• workflow,
• systémy,
• nástroje,
• úkoly,
• časové omezení,
• úroveň autonomie.

Scope má zabránit tomu, aby se agent postupně rozšířil do oblastí, pro které nebyl schválen.

Minimum requirement

AI team member musí mít definovaný scope a pravidla pro jeho změnu.

9. Allowed inputs

AI team member musí mít definované povolené vstupy.

Příklady:

• public documents,
• selected internal knowledge artefacts,
• approved workflow descriptions,
• submitted change proposals,
• anonymized support tickets,
• backlog items,
• approved design screenshots,
• non-restricted decision records.

Allowed inputs musí odpovídat AI-NDA Boundary.

Minimum requirement

AI team member musí mít definované, jaké vstupy smí zpracovávat.

10. Forbidden inputs

AI team member musí mít definované zakázané vstupy.

Příklady:

• secrets,
• credentials,
• raw personal data,
• unrestricted customer data,
• restricted HR records,
• legal privileged documents,
• security vulnerabilities without approval,
• unapproved Operational DNA,
• documents outside scope.

Forbidden inputs musí být chráněny pravidly a podle možností technicky.

Minimum requirement

AI team member musí mít definované, jaké vstupy nesmí zpracovávat.

11. Allowed actions

AI team member musí mít jasně definované povolené akce.

Příklady:

• summarize,
• classify,
• detect missing metadata,
• propose cleanup,
• draft change proposal,
• suggest decision level,
• prepare review checklist,
• identify duplicate content,
• generate draft skill update,
• create risk note,
• prepare decision support,
• validate structure,
• create maintenance task draft.

Allowed actions mohou být různé podle autonomy level.

Minimum requirement

AI team member musí mít explicitně popsané allowed actions.

12. Forbidden actions

AI team member musí mít jasně definované zakázané akce.

Příklady:

• approve significant change,
• change active workflow without review,
• delete source of truth content,
• change sensitivity classification,
• access data outside AI-NDA Boundary,
• publish external content without approval,
• make financial commitment,
• decide values conflict,
• change Operational DNA without owner review,
• update permissions,
• hide uncertainty,
• store restricted content in agent memory without approval.

Minimum requirement

AI team member musí mít explicitně popsané forbidden actions.

13. Permissions

AI team member musí mít přístupová oprávnění podle principů:

least privilege
need to know
purpose limitation
auditability
revocation

Oprávnění mohou být:

• read-only,
• propose-only,
• draft-write,
• write-with-approval,
• execute-approved-low-risk-actions,
• no-access-to-restricted-data,
• no-access-to-operational-dna,
• temporary-access.

Minimum requirement

AI team member s přístupem k neveřejnému know-how musí mít definovaná a auditovatelná permissions.

14. Autonomy level

AI team member musí mít definovanou úroveň autonomie.

Doporučená škála:

0 %  — no autonomous action
25 % — proposes only
50 % — creates drafts, human approves
75 % — executes approved low-risk actions with review gates
100 % — operates autonomously only inside strict pre-approved boundaries

Autonomie musí být kontextová.

Stejný agent může mít:

• 75 % autonomii pro detekci chybějících metadat,
• 50 % autonomii pro draft change proposals,
• 0 % autonomii pro změnu Operational DNA.

Minimum requirement

AI team member musí mít definovanou autonomii podle typů akcí.

15. Approval rules

AI team member musí vědět, kdy je potřeba approval.

Approval může být vyžadován při:

• změně source of truth,
• publikaci externího výstupu,
• práci s restricted daty,
• změně workflow,
• změně AI-NDA Boundary,
• změně Operational DNA,
• vytvoření decision record,
• navržení změny hodnotového výkladu,
• významném dopadu na jinou komunitu.

Approval musí být dohledatelný.

Minimum requirement

AI team member musí mít pravidla, které výstupy a akce vyžadují human nebo community approval.

16. Output types

AI team member musí mít definované typy výstupů.

Příklady:

• summary,
• draft,
• analysis,
• recommendation,
• change proposal,
• maintenance proposal,
• risk note,
• decision support,
• skill update proposal,
• validation report,
• incident signal,
• backlog item draft.

Výstup musí být označen podle statusu.

AI výstup není automaticky approved knowledge.

Minimum requirement

AI team member output musí být jasně odlišitelný od schváleného source of truth.

17. Write-back rules

AI team member musí mít pravidla pro zápis zpět do source of truth.

Může mít například právo:

• vytvořit draft artefakt,
• vytvořit proposal,
• přidat komentář,
• označit issue,
• vytvořit maintenance task,
• připravit pull request,
• aktualizovat metadata v low-risk oblasti,
• nebo pouze navrhnout změnu.

U kritického obsahu musí být write-back schválený.

Minimum requirement

AI team member nesmí zapisovat do active source of truth bez definovaných write-back rules.

18. Memory rules

AI team member může, ale nemusí mít paměť.

Agent memory je riziková, pokud obsahuje:

• restricted data,
• Operational DNA,
• zákaznické informace,
• rozhodovací logiku,
• skills,
• interní strategii.

Memory rules musí definovat:

• co se ukládá,
• co se neukládá,
• kdo memory vidí,
• jak se memory maže,
• jak se exportuje,
• jak se audituje,
• jak se brání tomu, aby memory nahradila source of truth.

Minimum requirement

AI team member memory nesmí být autoritativní source of truth.

19. Source of truth relationship

AI team member musí pracovat vůči source of truth.

To znamená:

• čte schválenou znalost podle oprávnění,
• rozlišuje active, draft, deprecated a rejected obsah,
• generuje návrhy jako návrhy,
• neukládá kritické know-how pouze do chatu nebo memory,
• propojuje výstupy s decision records,
• vrací významné know-how do source of truth přes review.

AI team member nesmí vytvořit paralelní neformální knowledge base.

Minimum requirement

AI team member musí mít definovaný vztah k source of truth.

20. Human Cockpit Layer relationship

Human Cockpit Layer musí AI team membery zviditelňovat.

Odpovědní členové komunity by měli vidět:

• jméno nebo identitu agenta,
• roli,
• ownera,
• scope,
• status,
• autonomy level,
• AI-NDA Boundary,
• oprávnění,
• poslední výstupy,
• čekající approvals,
• rizika,
• cost usage,
• value contribution,
• incidenty,
• memory status,
• fallback,
• možnost vypnutí.

Bez této viditelnosti se AI agenti mohou stát neviditelnou pracovní silou bez governance.

Minimum requirement

Významní AI team members musí být lidsky viditelní v Human Cockpit Layer nebo ekvivalentním governance rozhraní.

21. Naming and identity

AI team member musí mít jasnou identitu.

Identita může obsahovat:

• jméno,
• role ID,
• ownera,
• verzi,
• scope,
• status.

Příklad:

Knowledge Maintenance Agent
id: agent_kma_4f91
version: 0.3
owner: knowledge-owner
status: active

Jméno agenta by nemělo vytvářet iluzi lidské odpovědnosti.

Příliš antropomorfní prezentace může zastřít, že odpovědnost nese člověk nebo komunita.

Minimum requirement

AI team member musí mít stabilní identitu a nesmí zakrývat svého human ownera.

22. Onboarding of AI team member

AI team member musí být uveden do týmu řízeně.

Onboarding může zahrnovat:

• definici role,
• definici scope,
• nastavení oprávnění,
• přidělení ownera,
• schválení AI-NDA Boundary,
• definici allowed/forbidden actions,
• testovací režim,
• review výstupů,
• nastavení cost limitu,
• nastavení fallbacku,
• komunikaci týmu, co agent smí a nesmí.

Minimum requirement

AI team member s významným dopadem nesmí být zapojen bez onboarding záznamu.

23. Offboarding of AI team member

AI team member musí být možné bezpečně vypnout nebo odebrat.

Offboarding musí řešit:

• odebrání oprávnění,
• uzavření rozpracovaných úkolů,
• export nebo smazání memory,
• zápis relevantního know-how do source of truth,
• vyhodnocení přínosu,
• kontrolu dependency,
• zrušení napojení na nástroje,
• archivaci agent recordu,
• incident check.

Minimum requirement

AI team member musí mít offboarding mechanismus.

24. Performance and value measurement

AI team member musí být vyhodnocován podle hodnoty, ne pouze aktivity.

Nemá stačit:

• kolik textu vytvořil,
• kolik návrhů poslal,
• kolik ticketů prošel.

Důležité je:

• kolik užitečných návrhů bylo přijato,
• kolik dluhu pomohl snížit,
• kolik rizik odhalil,
• kolik review práce přidal,
• kolik šumu vytvořil,
• kolik AI dependency způsobil,
• kolik know-how se vrátilo do source of truth,
• zda zlepšil human capability nebo ji oslabil.

Minimum requirement

Významný AI team member musí mít pravidelné vyhodnocení přínosu, nákladů, rizik a závislosti.

25. Cost visibility

AI team member spotřebovává zdroje.

Může spotřebovávat:

• tokeny,
• API náklady,
• compute,
• human review time,
• attention,
• governance capacity,
• bezpečnostní kapacitu.

Cost musí být viditelný.

Pokud AI team member nemá měřenou spotřebu, komunita neumí rozhodnout, zda jeho přínos odpovídá nákladům.

Minimum requirement

Významný AI team member musí mít cost visibility nebo alespoň cost estimate.

26. Risk management

AI team member může vytvářet rizika.

Příklady:

• nesprávné návrhy,
• halucinace,
• práce s nevhodnými daty,
• přístup mimo scope,
• příliš vysoká autonomie,
• skryté rozhodování,
• AI dependency,
• AI lock-in,
• knowledge leakage,
• over-trust,
• under-review,
• ztráta lidské schopnosti,
• změna týmového chování.

Minimum requirement

AI team member s přístupem k neveřejným datům, source of truth nebo nástrojům musí mít risk assessment.

27. AI team member as proposer

AI team member může být silný zdroj change proposals.

Může navrhovat:

• cleanup,
• nové workflow,
• změnu priority,
• skill update,
• risk mitigation,
• AI dependency reduction,
• fallback,
• změnu AI-NDA Boundary,
• změnu operating mode,
• maintenance backlog item.

Ale návrh není rozhodnutí.

Minimum requirement

AI-generated change proposals musí být označené jako AI-generated a projít governance lifecycle.

28. AI team member in decision support

AI team member může připravovat rozhodovací podklady.

Může:

• shrnout kontext,
• porovnat alternativy,
• odhadnout rizika,
• identifikovat dotčené hodnoty,
• navrhnout decision level,
• připravit decision record draft.

AI team member nesmí skrytě rozhodovat tím, že jeho doporučení je bez review automaticky přijato.

Minimum requirement

Decision support agent musí jasně rozlišovat analysis, recommendation a decision.

29. AI team member in maintenance

Maintenance agent může pomáhat s péčí o knowledge base a workflow.

Může hledat:

• outdated artefacts,
• missing owners,
• missing review,
• duplicate content,
• metadata conflicts,
• deprecated content still referenced,
• AI workflow without fallback,
• Operational DNA without owner,
• restricted content with unsafe AI access.

To, o co komunita nepečuje, má tendenci degradovat nebo vytvářet dluh.

AI maintenance agent může tuto péči zrychlit, ale nevlastní odpovědnost za knowledge base.

Minimum requirement

Maintenance agent smí navrhovat a připravovat údržbu, ale kritické změny musí mít owner review.

30. AI team member in support

Support agent může pomáhat s triage, odpověďmi, sumarizací a detekcí patternů.

Rizika support agenta:

• práce s osobními daty,
• halucinace vůči zákazníkovi,
• neautorizované závazky,
• reputační dopad,
• ztráta kontaktu lidí se zákaznickou realitou,
• neviditelný customer signal.

Minimum requirement

Support AI team member musí mít jasná pravidla pro customer-facing výstupy, data sensitivity a escalation.

31. AI team member in development

Development agent může pomáhat s:

• návrhem kódu,
• testy,
• refactoringem,
• dokumentací,
• code review,
• detekcí patternů,
• návrhem technického řešení.

Rizika:

• vývojářská AI dependency,
• špatné pochopení architektury,
• security slabiny,
• neudržované změny,
• ztráta juniorního učení,
• vendor/model dependency.

Minimum requirement

Development AI team member musí podporovat human capability, ne ji nahrazovat. Kritické změny musí mít review a vazbu na source of truth.

32. AI team member and human capability

AI team member nesmí způsobit, že lidé ztratí schopnost chápat nebo vykonávat práci.

AI může dělat práci rychleji.

Ale komunita musí udržovat:

• schopnost zadat práci,
• schopnost zkontrolovat výstup,
• schopnost opravit chybu,
• schopnost pokračovat bez AI,
• schopnost učit nového člena,
• schopnost porozumět vlastnímu systému.

Pokud AI team member zrychlí tým, ale zároveň odstraní lidské učení, vzniká skrytý dluh.

Minimum requirement

AI team member musí být pravidelně vyhodnocován z hlediska dopadu na Human Capability Reserve.

33. AI team member and AI-NDA Boundary

AI team member musí pracovat uvnitř AI-NDA Boundary.

Pokud se změní:

• role,
• data,
• scope,
• model,
• vendor,
• memory,
• output type,
• autonomy level,

může být nutné aktualizovat boundary.

Minimum requirement

AI team member nesmí zpracovávat neveřejné know-how mimo schválenou AI-NDA Boundary.

34. AI team member and Operational DNA

AI team member může mít přístup k Operational DNA pouze tehdy, pokud je to výslovně schválené.

Operational DNA přístup vyžaduje:

• explicitní účel,
• omezený scope,
• ownera,
• audit,
• AI-NDA Boundary,
• memory pravidla,
• výstupní review,
• exit strategy,
• fallback.

Minimum requirement

AI team member s přístupem k Operational DNA musí být označen jako high-risk nebo critical agent.

35. AI team member record

AIFC doporučuje pro AI team membera používat agent record.

Příklad metadat:

ai_team_member:
  id:
  name:
  role:
  status: draft | proposed | active | paused | deprecated | retired | revoked
  owner:
  purpose:
  scope:
  allowed_inputs:
  forbidden_inputs:
  allowed_actions:
  forbidden_actions:
  permissions:
  autonomy_level:
  approval_rules:
  ai_nda_boundary:
  memory_allowed: true | false
  memory_rules:
  source_of_truth_access:
    read: true | false
    write: none | draft | proposal | approved_low_risk | active_with_approval
  operational_dna_access: true | false
  cost_limit:
  risk_level:
  review_cycle:
  last_reviewed:
  fallback:
  offboarding_plan:

Tato struktura je ilustrativní.

Finální schéma má být definováno v agent-actionable vrstvě standardu.

36. Anti-patterns

AIFC odmítá následující anti-patterny.

36.1 AI agent without owner

Agent pracuje v týmu, ale nikdo za něj neodpovídá.

36.2 AI agent without role

Není jasné, k čemu agent existuje.

36.3 AI agent with unlimited scope

Agent postupně získá přístup ke všemu.

36.4 AI agent with hidden permissions

Tým neví, co agent smí číst nebo měnit.

36.5 AI agent as hidden decision maker

AI doporučení se v praxi automaticky přijímá jako rozhodnutí.

36.6 AI agent memory as source of truth

Agent si pamatuje důležité know-how, které není zapsané v source of truth.

36.7 AI agent without offboarding

Agenta nelze bezpečně vypnout, odebrat nebo nahradit.

36.8 AI agent without cost visibility

Agent spotřebovává zdroje, ale nikdo neví kolik a s jakým přínosem.

36.9 AI agent causing human degradation

Agent zrychlí práci, ale lidé ztratí schopnost práci pochopit nebo vykonat.

36.10 AI agent anthropomorphism

Agent je prezentován tak, že zastírá absenci lidské odpovědnosti.

37. Minimal requirements

AIFC komunita musí v oblasti AI as Team Member minimálně splnit:

1. AI team member má jasnou roli.
2. AI team member má human nebo community ownera.
3. AI team member má definovaný scope.
4. AI team member má allowed inputs.
5. AI team member má forbidden inputs.
6. AI team member má allowed actions.
7. AI team member má forbidden actions.
8. AI team member má definovaná permissions.
9. AI team member má definovanou autonomy level.
10. AI team member má approval rules.
11. AI výstupy jsou odlišeny od approved source of truth.
12. AI team member má write-back rules.
13. AI memory není autoritativní source of truth.
14. AI team member je napojený na source of truth.
15. Významný AI team member je viditelný v Human Cockpit Layer nebo governance rozhraní.
16. AI team member má onboarding mechanismus.
17. AI team member má offboarding mechanismus.
18. Významný AI team member má cost visibility.
19. AI team member s neveřejnými daty má AI-NDA Boundary.
20. AI team member s Operational DNA přístupem má explicitní schválení a audit.
21. AI-generated change proposals procházejí governance lifecycle.
22. AI team member je vyhodnocován z hlediska dopadu na Human Capability Reserve.

38. Summary

AI team member je řízená AI pracovní kapacita uvnitř komunity.

Může výrazně pomoci s prací, znalostmi, údržbou, návrhy, podporou rozhodování a učením systému.

Ale AI team member nesmí být neviditelný aktér bez hranic.

AIFC proto říká:

Give AI a role.
Give it boundaries.
Give it an owner.
Give it audit.
Give humans the decision.
Keep knowledge in the source of truth.
Keep the community capable without it.

Česky:

Dejte AI roli.
Dejte jí hranice.
Dejte jí ownera.
Dejte jí audit.
Rozhodnutí nechte lidem.
Know-how držte v source of truth.
Udržte komunitu schopnou fungovat i bez ní.

AI agent může být členem pracovního systému.

Nesmí se stát vlastníkem komunity.

AI as Team Member turns AI agents into governed community roles.