AIFC-061: Access Control

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-012 Metadata and Markdown
• AIFC-020 Human-Managed AI
• AIFC-022 AI-NDA Boundary
• AIFC-023 AI as Team Member
• AIFC-034 AI Lock-in and Exit Strategy
• AIFC-050 Community Interface
• AIFC-060 Knowledge Security

Účel dokumentu: Definovat Access Control jako řízený mechanismus přístupu lidí, AI agentů, systémů, dodavatelů a komunit ke knowledge base, source of truth, Operational DNA, skills, rozhodnutím, workflows a rozhraním. Access Control chrání nejen data, ale schopnost, odpovědnost, integritu a důvěru komunity.

1. Purpose of this document

Tento dokument definuje Access Control.

AIFC komunita pracuje se znalostmi, které mohou být veřejné, interní, citlivé nebo kritické.

Access Control říká:

• kdo smí číst,
• kdo smí měnit,
• kdo smí schvalovat,
• kdo smí exportovat,
• kdo smí sdílet,
• kdo smí zapojit AI,
• kdo smí dát přístup dodavateli,
• kdo smí pracovat s Operational DNA,
• kdo smí změnit klasifikaci,
• kdo smí změnit AI-NDA Boundary,
• kdo smí změnit agent permissions,
• kdo smí publikovat výstup ven.

V AIFC není Access Control pouze technické nastavení oprávnění.

Je to governance mechanismus, který chrání vlastnictví know-how, důvěru, odpovědnost a schopnost komunity.

2. Core principle

Základní princip tohoto dokumentu je:

Access to knowledge is access to community capability.

Česky:

Přístup ke know-how je přístup ke schopnosti komunity.

AIFC říká:

Grant access by purpose, role, sensitivity and responsibility — not by convenience.

Česky:

Přístup udělujte podle účelu, role, citlivosti a odpovědnosti — ne podle pohodlí.

Access Control nemá práci zbytečně brzdit.

Má zajistit, že schopnost komunity je sdílena správně, bezpečně a odpovědně.

3. Definition

Access Control je soubor pravidel, rolí, oprávnění, schvalování, auditů a revokačních mechanismů, které určují, kdo nebo co smí přistupovat ke knowledge artefaktům a jaké akce s nimi smí provádět.

Access Control se vztahuje na:

• lidi,
• AI agenty,
• AI nástroje,
• systémy,
• integrace,
• dodavatele,
• externí experty,
• service accounts,
• partnerské komunity,
• veřejnost,
• Human Cockpit Layer,
• retrieval systémy,
• vector stores,
• exporty.

Access Control definuje nejen přístup k datům, ale i přístup k akcím.

Minimum requirement

Každý významný knowledge artefakt nebo knowledge system musí mít řízený přístup přiměřený své klasifikaci a dopadu.

4. Why Access Control matters

Bez řízeného přístupu vznikají rizika:

• únik know-how,
• únik Operational DNA,
• neoprávněné AI zpracování,
• neautorizované změny source of truth,
• nejasné schvalování,
• nevratné exporty,
• vendor lock-in,
• agentické akce mimo scope,
• tiché přepsání rozhodnutí,
• zneužití citlivých metadat,
• ztráta důvěry,
• nemožnost auditu,
• ztráta schopnosti řídit komunitu.

Access Control není jen ochrana před útočníkem.

Chrání také před nechtěným sdílením, nejasným vlastnictvím, nástroji bez boundary a AI agenty bez odpovědnosti.

Minimum requirement

AIFC komunita musí chápat Access Control jako ochranu znalostní a provozní schopnosti, ne jen jako IT permission model.

5. Access is action-specific

Přístup není jedna hodnota.

Nestačí říct:

User has access.

Je potřeba říct, jaký typ přístupu.

Možné akce:

read
comment
propose
edit draft
approve
publish
export
share
classify
declassify
delete
archive
restore
grant access
revoke access
process with AI
write back from AI
run agent
modify agent permissions

Někdo může smět číst, ale nesmí exportovat. Někdo může smět navrhnout změnu, ale nesmí ji schválit. AI může smět sumarizovat public obsah, ale nesmí zapisovat do source of truth.

Minimum requirement

Kritické artefakty musí rozlišovat alespoň read, write, approve, export and AI processing permissions.

6. Role-based access

Role-based access přiřazuje oprávnění podle role.

Příklady rolí:

• community owner,
• knowledge owner,
• artefact owner,
• contributor,
• reviewer,
• approver,
• security owner,
• AI governance owner,
• AI team member owner,
• external expert,
• vendor,
• auditor,
• public reader.

Role-based access je důležitý základ.

Ale nestačí.

Musí být doplněn o purpose limitation, classification a context.

Minimum requirement

AIFC komunita musí mít definované role pro přístup ke kritickým knowledge artefaktům.

7. Purpose-based access

Purpose-based access říká, že přístup je oprávněný jen pro konkrétní účel.

Příklad:

Vendor may access restricted workflow documentation only for migration assessment, not for training its own AI models or reuse in other customers.

Účel omezuje:

• co lze číst,
• co lze zpracovat AI,
• zda lze exportovat,
• zda lze ukládat kopie,
• zda lze vytvářet derived knowledge,
• jak dlouho přístup trvá.

Minimum requirement

Restricted knowledge a Operational DNA musí používat purpose limitation.

8. Least privilege

Least privilege znamená, že subjekt má pouze takový přístup, který potřebuje.

To platí pro:

• lidi,
• AI agenty,
• dodavatele,
• integrace,
• service accounts,
• retrieval systems.

Příklad:

• maintenance agent nepotřebuje přístup k finance strategy,
• UX agent nepotřebuje customer personal data,
• vendor nepotřebuje celý source of truth,
• AI summarizer nepotřebuje write access.

Minimum requirement

Přístup k restricted knowledge a Operational DNA musí být založen na least privilege.

9. Need-to-know

Need-to-know znamená, že člen nebo systém má přístup pouze tehdy, když jej skutečně potřebuje pro úkol.

Není dostatečné říct:

Je členem firmy.

Je potřeba říct:

Potřebuje tento konkrétní artefakt pro tento konkrétní účel?

Minimum requirement

Operational DNA musí být přístupná pouze subjektům s jasným need-to-know.

10. Access by classification

Access Control musí respektovat klasifikaci.

Doporučené vrstvy:

Public
Internal
Restricted
Operational DNA

Public

Může být čteno veřejně.

Internal

Čtení je omezené na komunitu nebo organizaci.

Restricted

Přístup je omezen podle role, účelu a approval.

Operational DNA

Přístup je vysoce omezený, auditovaný a schvalovaný.

Minimum requirement

Access rules musí být definována pro každou klasifikační úroveň.

11. Public access

Public access znamená, že artefakt může vidět veřejnost.

Ale i public artefakt musí být řízený.

Rizika:

• public interface může odhalit Operational DNA,
• metadata mohou odhalit interní strukturu,
• AI-generated public text může být neschválený,
• public dokument může být zastaralý,
• public API může odhalit více, než bylo zamýšleno.

Minimum requirement

Public artefakty musí mít ownera, status a review proti citlivému úniku, pokud vycházejí z interní knowledge base.

12. Internal access

Internal access znamená přístup uvnitř komunity nebo organizace.

Internal neznamená automaticky bezpečné.

Rizika:

• příliš široký interní přístup,
• AI nástroje dostupné všem,
• kopírování citlivých částí do chatů,
• neřízené sdílení s externisty,
• slabý offboarding.

Minimum requirement

Internal knowledge musí mít pravidla pro AI use, external sharing a offboarding.

13. Restricted access

Restricted access se týká citlivých znalostí.

Může zahrnovat:

• zákaznické informace,
• security pravidla,
• interní strategy,
• vendor contracts,
• financial plans,
• incident records,
• restricted workflows,
• restricted AI skills,
• legal/compliance artefakty.

Restricted access vyžaduje:

• ownera,
• approval,
• need-to-know,
• audit,
• retention,
• AI-NDA Boundary.

Minimum requirement

Restricted artefakty musí mít ownera, approval rules a audit nebo access log přiměřený riziku.

14. Operational DNA access

Operational DNA access je nejcitlivější přístup.

Může umožnit pochopit nebo replikovat schopnost komunity.

Operational DNA access musí být:

• explicitně schválený,
• purpose-limited,
• časově omezený,
• auditovaný,
• minimální,
• revokovatelný,
• chráněný proti exportu,
• chráněný proti neřízenému AI zpracování,
• pravidelně revidovaný.

Minimum requirement

Operational DNA access musí mít explicitní approval, ownera, audit, purpose limitation a revocation path.

15. Human access

Human access je přístup lidí.

Musí řešit:

• zaměstnance,
• členy komunity,
• externisty,
• dodavatele,
• konzultanty,
• auditory,
• leadership,
• dočasné role,
• emergency access.

Human access musí být propojený s:

• rolí,
• účelem,
• trváním,
• školením,
• NDA nebo AI-NDA-like boundaries,
• offboardingem,
• access review.

Minimum requirement

Lidský přístup ke kritickým artefaktům musí být pravidelně revidován.

16. AI access

AI access je přístup AI nástroje, modelu, agenta nebo workflow ke knowledge artefaktům.

AI access musí definovat:

• allowed tools,
• allowed models,
• allowed artefacts,
• forbidden artefacts,
• memory rules,
• training rules,
• derived knowledge rules,
• prompt/output visibility,
• write-back permissions,
• audit,
• owner,
• revocation.

AI access není totéž jako human access.

To, že člověk smí číst dokument, neznamená, že jej smí vložit do libovolného AI nástroje.

Minimum requirement

AI access musí být explicitně povolen pro neveřejné knowledge artefakty.

17. Agent access

Agent access je zvláštní případ AI access.

Agent může nejen číst, ale také jednat.

Proto musí mít:

• identity,
• role,
• owner,
• scope,
• allowed actions,
• forbidden actions,
• tool access,
• data access,
• write access,
• approval boundary,
• cost guardrails,
• audit,
• kill switch,
• exit strategy.

Minimum requirement

AI agent s write access nebo tool access musí mít explicitní permissions record.

18. System access

System access zahrnuje aplikace, integrace, API, retrieval systémy, CI/CD, analyzátory, validátory a další technické služby.

Riziko vzniká, když systém:

• čte více, než potřebuje,
• zapisuje bez review,
• exportuje data,
• loguje citlivý obsah,
• vytváří embeddings,
• sdílí data s AI,
• má long-lived credentials.

Minimum requirement

Systémový přístup ke kritické knowledge base musí být řízený, auditovatelný a revokovatelný.

19. Vendor access

Vendor access musí být zvlášť řízený.

Dodavatel může potřebovat přístup pro:

• implementaci,
• support,
• migration,
• audit,
• consulting,
• AI setup,
• system integration.

Vendor access musí mít:

• purpose,
• scope,
• data boundary,
• AI use rules,
• retention rules,
• export rules,
• knowledge return obligation,
• audit,
• expiry,
• revocation,
• exit strategy.

Minimum requirement

Vendor access k restricted knowledge nebo Operational DNA musí mít explicitní ownerství, časové omezení a boundary.

20. Cross-community access

Cross-community access vzniká, když jedna komunita dává přístup jiné komunitě.

Může jít o:

• partnera,
• zákazníka,
• dodavatele,
• regulatora,
• open community,
• joint venture,
• federated governance.

Musí být definováno:

• co se sdílí,
• za jakým účelem,
• kdo odpovídá,
• jaká je klasifikace,
• zda je povolené AI zpracování,
• jak se řeší derived knowledge,
• jak se přístup ukončí.

Minimum requirement

Cross-community access k neveřejnému know-how musí mít data sharing boundary a ownera.

21. Access request

Access request je proces, kterým subjekt žádá o přístup.

Žádost by měla obsahovat:

• kdo žádá,
• k čemu potřebuje přístup,
• k jakým artefaktům,
• jakou akci potřebuje,
• na jak dlouho,
• zda použije AI,
• zda bude exportovat,
• zda vznikne derived knowledge,
• jaká je klasifikace,
• kdo schvaluje.

Minimum requirement

Přístup k restricted knowledge a Operational DNA musí být udělen přes schválený access request nebo ekvivalentní proces.

22. Access approval

Access approval musí být přiměřený riziku.

Může schvalovat:

• artefact owner,
• knowledge owner,
• security owner,
• AI governance owner,
• community owner,
• legal/compliance owner,
• Operational DNA owner.

Approval musí být silnější u:

• Operational DNA,
• AI processing,
• export,
• vendor access,
• cross-community access,
• public release,
• write permissions,
• declassification.

Minimum requirement

Kritický přístup musí být schválen odpovědnou rolí podle klasifikace a typu akce.

23. Time-bound access

Přístup nemá být trvalý, pokud není nutný.

Time-bound access je vhodný pro:

• vendory,
• konzultanty,
• audit,
• mission mode,
• migration,
• incident response,
• temporary project teams,
• AI experiments.

Minimum requirement

Dočasné nebo externí přístupy ke kritickým artefaktům musí mít expiration nebo review date.

24. Emergency access

Emergency access může být nutný při incidentu.

Musí být:

• omezený,
• auditovaný,
• odůvodněný,
• časově omezený,
• zpětně revidovaný.

Emergency access nesmí být trvalá zadní vrátka.

Minimum requirement

Emergency access ke kritickým znalostem musí být logovaný a následně reviewovaný.

25. Access revocation

Access revocation je schopnost odebrat přístup.

Revocation musí řešit:

• lidi,
• vendory,
• AI agenty,
• integrace,
• API keys,
• service accounts,
• retrieval systémy,
• vector stores,
• exported copies,
• agent memory,
• cached content.

Revocation musí být dostupná při:

• offboardingu,
• role change,
• incidentu,
• boundary violation,
• vendor exit,
• project end,
• AI tool deprecation.

Minimum requirement

Každý kritický přístup musí mít revocation path.

26. Offboarding

Offboarding je zvláštní případ revocation.

Musí zajistit:

• odebrání přístupu,
• předání know-how,
• zrušení credentials,
• odebrání AI tool access,
• zrušení agent permissions,
• kontrolu exportů,
• kontrolu lokálních kopií,
• zachování source of truth,
• audit.

Minimum requirement

Odchod osoby, vendora nebo agenta s přístupem ke kritickému know-how musí spustit offboarding checklist.

27. Access review

Access review pravidelně kontroluje, zda přístupy stále dávají smysl.

Otázky:

• Kdo má přístup?
• Proč?
• Je stále potřeba?
• Je scope správný?
• Je AI access stále povolený?
• Není přístup příliš široký?
• Existují orphaned accounts?
• Existují agenti bez ownera?
• Existují vendorská oprávnění po konci projektu?

Minimum requirement

Restricted knowledge a Operational DNA musí mít pravidelný access review.

28. Access audit

Audit musí umožnit zjistit:

• kdo četl,
• kdo změnil,
• kdo schválil,
• kdo exportoval,
• kdo sdílel,
• kdo použil AI,
• který agent jednal,
• s jakým nástrojem,
• kdy,
• s jakým účelem,
• a jaký byl výsledek.

Audit nemusí být stejně detailní pro všechno.

Musí odpovídat riziku.

Minimum requirement

Kritické akce nad restricted knowledge nebo Operational DNA musí být auditovatelné.

29. Export permissions

Export je vysoce riziková akce.

Export může obejít běžný access control.

Export permissions musí řešit:

• kdo smí exportovat,
• jaký rozsah,
• za jakým účelem,
• v jakém formátu,
• kam,
• zda lze export poslat AI,
• zda obsahuje metadata,
• zda obsahuje Operational DNA,
• zda je auditovaný,
• zda je šifrovaný,
• zda má retention.

Minimum requirement

Export restricted knowledge nebo Operational DNA musí vyžadovat explicitní permission a audit.

30. Sharing permissions

Sharing permissions řeší sdílení s jinými lidmi, týmy, komunitami nebo systémy.

Sdílení není totéž co čtení.

Člověk může smět číst dokument, ale nesmí ho sdílet dál.

AI může smět zpracovat interní dokument, ale nesmí poslat výstup externímu vendorovi.

Minimum requirement

Restricted knowledge musí rozlišovat read access a share access.

31. Write permissions

Write permissions určují, kdo smí měnit source of truth.

Musí rozlišovat:

• edit draft,
• propose change,
• update active content,
• approve change,
• publish,
• deprecate,
• archive,
• delete.

AI write access je zvlášť citlivý.

Minimum requirement

Kritické source of truth artefakty musí rozlišovat propose, edit, approve and publish permissions.

32. Approval permissions

Approval je vyšší oprávnění než editace.

Schválení může měnit status poznatku na platný.

Rizika:

• schválení AI outputu bez review,
• schválení vlastního návrhu bez nezávislé kontroly,
• schválení změny values, AI-NDA Boundary nebo Operational DNA pravidel bez governance,
• automatické approvaly bez ownera.

Minimum requirement

Kritické schválení musí být oddělené od běžné editace a musí mít odpovědného ownera.

33. Classification permissions

Změna klasifikace je citlivá akce.

Declassification může odhalit know-how.

Reclassification může zablokovat práci.

AI může klasifikaci navrhnout, ale neměla by sama snížit citlivost kritického artefaktu.

Minimum requirement

Snížení klasifikace restricted nebo Operational DNA artefaktu musí vyžadovat approval.

34. AI processing permission

AI processing permission říká, zda lze artefakt vložit do AI, zpracovat agentem nebo použít v retrieval.

Musí rozlišovat:

• AI allowed,
• AI allowed with approved tools only,
• AI allowed only with redaction,
• AI allowed only in private environment,
• AI forbidden,
• AI requires owner approval,
• AI requires AI-NDA Boundary.

Minimum requirement

Každý restricted nebo Operational DNA artefakt musí mít jasné AI processing pravidlo nebo jej dědit z klasifikace.

35. Human Cockpit Layer access

Human Cockpit Layer může agregovat přístup k mnoha artefaktům.

Musí respektovat:

• user role,
• artefact classification,
• AI access,
• interface scope,
• aggregation risk,
• derived knowledge,
• visibility of metadata,
• decision rights.

Cockpit nesmí zobrazit uživateli syntézu z dat, ke kterým by jednotlivě neměl přístup.

Minimum requirement

Human Cockpit Layer musí respektovat stejná nebo přísnější access rules než source of truth.

36. Retrieval access

AI retrieval může skládat odpověď z mnoha dokumentů.

Retrieval access musí zajistit:

• user má právo na všechny použité zdroje,
• agent má právo na všechny použité zdroje,
• odpověď neodhalí restricted obsah,
• metadata nejsou uniklá,
• embeddings jsou správně izolované,
• výsledky jsou filtrovány podle oprávnění.

Minimum requirement

AI retrieval nesmí obcházet access control přes agregované odpovědi.

37. Access to metadata

Metadata mohou být citlivá.

Přístup k metadatům musí řešit:

• owner,
• status,
• priority,
• classification,
• risk level,
• AI access,
• related artefacts,
• decision state,
• Operational DNA mapping.

Někdy je metadata potřeba chránit stejně jako obsah.

Minimum requirement

Metadata access musí být řízený u restricted a Operational DNA artefaktů.

38. Access and source of truth write-back

Pokud AI nebo člověk vytvoří výstup, který se má zapsat do source of truth, musí mít oprávnění pro write-back.

Write-back musí řešit:

• kdo zapisuje,
• zda jde o draft,
• zda jde o proposal,
• zda je potřeba review,
• kdo schvaluje,
• jak se označí AI-generated content,
• jak se uloží lineage.

Minimum requirement

AI write-back do source of truth musí být omezený, auditovaný a typicky začínat jako draft nebo proposal.

39. Access and separation of duties

Některé akce musí být oddělené.

Například:

• autor návrhu není schvalovatel,
• AI agent nenavrhuje a neschvaluje totéž,
• vendor nemůže sám schválit vlastní výstup,
• osoba, která snižuje klasifikaci, není jediný reviewer,
• agent, který vytváří change proposal, jej nemůže označit jako accepted.

Minimum requirement

Kritická rozhodnutí a změny musí používat separation of duties přiměřeně riziku.

40. Access and values

Access Control musí být v souladu s hodnotami.

Například:

• hodnota důvěry vyžaduje transparentní přístup,
• hodnota bezpečnosti vyžaduje omezený přístup,
• hodnota learning vyžaduje přístup k neškodným příkladům,
• hodnota resilience vyžaduje, aby know-how nebylo uvězněné u jednoho člověka,
• hodnota privacy vyžaduje minimalizaci.

Příliš přísný access control může zabít učení. Příliš volný access control může zničit důvěru.

Minimum requirement

Access rules musí vyvažovat bezpečnost, učení, odpovědnost a provozní potřebu.

41. Access and Human Capability Reserve

Access Control nesmí nechtěně zničit Human Capability Reserve.

Pokud kritické know-how vidí jen AI agent nebo úzká skupina, komunita ztrácí schopnost obnovy.

Je potřeba zajistit:

• přiměřené lidské know-how,
• záložní role,
• fallback přístup,
• training přístup k bezpečným verzím,
• redigované learning examples,
• emergency access.

Minimum requirement

Kritické know-how musí být dostupné dostatečnému počtu odpovědných lidí, aby komunita neztratila schopnost recovery.

42. Access and AI lock-in

Access Control musí chránit před AI lock-inem.

Riziko vzniká, když:

• AI vendor drží knowledge,
• agent memory obsahuje kritický kontext,
• skills jsou v proprietární platformě,
• export není dostupný,
• access logs nejsou dostupné,
• vendor může omezit přístup k vlastní knowledge.

Minimum requirement

Access to critical knowledge through AI vendor systems must support exit strategy and exportability.

43. Access incident

Access incident je situace, kdy přístup poruší pravidla.

Příklady:

• neoprávněný uživatel získá přístup,
• AI tool zpracuje restricted data bez boundary,
• vendor si stáhne více dat, než bylo schváleno,
• agent provede zakázanou akci,
• export obsahuje Operational DNA,
• metadata uniknou přes dashboard,
• retrieval odpověď odhalí restricted obsah.

Minimum requirement

Access incidents musí být zaznamenány, triagovány a řešeny jako knowledge security incidents.

44. Suggested metadata

Příklad metadat pro access policy:

access_policy:
  id:
  title:
  status: draft | active | under_review | deprecated | archived
  owner:
  scope:
  applies_to_classification:
    - public
    - internal
    - restricted
    - operational_dna
  human_access:
    allowed_roles:
    approval_required: true | false
    review_cycle:
  ai_access:
    allowed: true | false
    allowed_tools:
    allowed_models:
    ai_nda_boundary:
    memory_allowed: true | false
    training_allowed: true | false
  actions:
    read:
    comment:
    propose:
    edit:
    approve:
    publish:
    export:
    share:
    delete:
    classify:
    declassify:
    process_with_ai:
    write_back_from_ai:
  audit_required: true | false
  revocation_required: true | false
  emergency_access_allowed: true | false
  last_reviewed:

Příklad metadat pro access request:

access_request:
  id:
  title:
  status: requested | under_review | approved | rejected | expired | revoked
  requester:
  requester_type: human | ai_agent | system | vendor | community
  requested_access_to:
  requested_actions:
  purpose:
  classification:
  ai_processing_requested: true | false
  export_requested: true | false
  duration:
  approver:
  approval_reason:
  conditions:
  expires_at:
  audit_required: true | false

Příklad metadat pro agent permissions:

agent_permissions:
  agent_id:
  owner:
  scope:
  allowed_artefacts:
  forbidden_artefacts:
  allowed_actions:
  forbidden_actions:
  write_access: none | draft_only | proposal_only | approved_scope
  export_allowed: true | false
  memory_allowed: true | false
  tools_allowed:
  approval_boundary:
  audit_required: true
  kill_switch:
  review_cycle:

Tyto struktury jsou ilustrativní.

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

45. Anti-patterns

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

45.1 Everyone can read everything

Interní otevřenost bez klasifikace odhalí restricted knowledge a Operational DNA.

45.2 Human access implies AI access

Člověk smí dokument číst, a proto jej vloží do libovolného AI nástroje.

45.3 Agent with admin access

AI agent má příliš široká oprávnění, protože je to pohodlné.

45.4 Vendor access without expiry

Dodavatel má přístup dlouho po skončení projektu.

45.5 Export without governance

Někdo exportuje knowledge base bez approval a auditu.

45.6 Draft write equals approved change

Možnost editovat návrh je zaměněna za právo změnit active source of truth.

45.7 AI declassifies knowledge

AI sama sníží citlivost artefaktu bez review.

45.8 Retrieval bypass

AI odpověď odhalí obsah, ke kterému uživatel neměl přístup.

45.9 No revocation path

Přístup nelze rychle odebrat při incidentu.

45.10 Access only by tool permissions

Komunita spoléhá jen na technické permissiony nástroje a neřeší purpose, AI boundary, export ani derived knowledge.

45.11 Over-restriction kills learning

Vše je tak uzamčené, že komunita ztrácí schopnost učení a onboarding.

45.12 Single human bottleneck

Kritické know-how má přístupné jen jeden člověk, takže komunita nemá recovery schopnost.

46. Minimal requirements

AIFC komunita musí v oblasti Access Control minimálně splnit:

1. Významné knowledge artefakty mají řízený přístup podle klasifikace a dopadu.
2. Access Control je chápán jako ochrana schopnosti komunity, ne jen IT permission model.
3. Kritické artefakty rozlišují read, write, approve, export and AI processing permissions.
4. Komunita má definované role pro přístup ke kritickým artefaktům.
5. Restricted knowledge a Operational DNA používají purpose limitation.
6. Přístup k restricted knowledge a Operational DNA je založen na least privilege.
7. Operational DNA je přístupná pouze s jasným need-to-know.
8. Access rules jsou definována pro klasifikační úrovně.
9. Public artefakty mají ownera, status a review proti citlivému úniku, pokud vycházejí z interní knowledge base.
10. Internal knowledge má pravidla pro AI use, external sharing a offboarding.
11. Restricted artefakty mají ownera, approval rules a audit nebo access log.
12. Operational DNA access má explicitní approval, ownera, audit, purpose limitation a revocation path.
13. Lidský přístup ke kritickým artefaktům je pravidelně revidován.
14. AI access je explicitně povolen pro neveřejné knowledge artefakty.
15. AI agent s write access nebo tool access má permissions record.
16. Systémový přístup ke kritické knowledge base je řízený, auditovatelný a revokovatelný.
17. Vendor access k restricted knowledge nebo Operational DNA má ownerství, časové omezení a boundary.
18. Cross-community access k neveřejnému know-how má data sharing boundary a ownera.
19. Přístup k restricted knowledge a Operational DNA je udělen přes schválený access request nebo ekvivalent.
20. Kritický přístup je schválen odpovědnou rolí podle klasifikace a akce.
21. Dočasné nebo externí přístupy ke kritickým artefaktům mají expiration nebo review date.
22. Emergency access je logovaný a následně reviewovaný.
23. Každý kritický přístup má revocation path.
24. Offboarding osoby, vendora nebo agenta spouští checklist.
25. Restricted knowledge a Operational DNA mají pravidelný access review.
26. Kritické akce nad restricted knowledge nebo Operational DNA jsou auditovatelné.
27. Export restricted knowledge nebo Operational DNA vyžaduje permission a audit.
28. Restricted knowledge rozlišuje read access a share access.
29. Kritické source of truth artefakty rozlišují propose, edit, approve and publish permissions.
30. Kritické schválení je oddělené od běžné editace.
31. Snížení klasifikace restricted nebo Operational DNA artefaktu vyžaduje approval.
32. Restricted nebo Operational DNA artefakt má AI processing pravidlo nebo jej dědí z klasifikace.
33. Human Cockpit Layer respektuje stejná nebo přísnější access rules než source of truth.
34. AI retrieval neobchází access control přes agregované odpovědi.
35. Metadata access je řízený u restricted a Operational DNA artefaktů.
36. AI write-back do source of truth je omezený, auditovaný a typicky začíná jako draft nebo proposal.
37. Kritická rozhodnutí a změny používají separation of duties přiměřeně riziku.
38. Access rules vyvažují bezpečnost, učení, odpovědnost a provozní potřebu.
39. Kritické know-how je dostupné dostatečnému počtu odpovědných lidí pro recovery.
40. Access through AI vendor systems supports exit strategy and exportability.
41. Access incidents jsou řešeny jako knowledge security incidents.

47. Summary

Access Control v AIFC není jen otázka, kdo otevře soubor.

Je to otázka, kdo má přístup ke schopnosti komunity.

Kdo smí číst její záměr. Kdo smí měnit její rozhodnutí. Kdo smí použít její know-how v AI. Kdo smí exportovat její Operational DNA. Kdo smí schválit změnu. Kdo smí dát přístup agentovi. Kdo smí rozhodnout, že něco už není citlivé.

AIFC proto říká:

Control access to knowledge.
Control access to actions.
Control access to AI processing.
Control access to community capability.

Česky:

Řiďte přístup ke znalostem.
Řiďte přístup k akcím.
Řiďte přístup k AI zpracování.
Řiďte přístup ke schopnosti komunity.

Dobře nastavený Access Control umožňuje spolupráci bez chaosu, AI akceleraci bez neřízeného úniku a sdílení znalostí bez ztráty vlastnictví.

Access Control turns knowledge access into governed community trust.