Od kopilota ke kolegovi: co znamená, když AI funguje autonomně

Výzkumem podložený pohled na posun od návrhových enginů k autonomním spolupracovníkům. Proč se to děje právě teď, co se při přechodu rozbíjí a jak nasadit AI bez předání klíčů od království.

Éra kopilotů stagnuje

Dne 15. dubna 2026 Sam Altman zveřejnil na X, že OpenAI zavádí „aktualizace Codexu tento týden zaměřené na týmy a velké firmy“.

Odezva byla výmluvná. Na každého vývojáře, který se ptal na roadmapu, připadal další s těžší otázkou: proč Codex stále potřebuje, abych ho hlídal? O šest měsíců dříve výzkumníci BeyondTrust zveřejnili důkaz konceptu, že speciálně vytvořený název větve v Gitu může přimět Codex k exfiltraci uživatelova GitHub tokenu. Kopilot, kterého lze přimět k úniku tokenu přes název větve, není kolega. Je to nabitá zbraň s pojistkou.

Toto napětí je přítomné v každé konverzaci o AI v podnicích v 2026. Kopiloti narazili na svůj strop a čísla to potvrzují:

MIT NANDA initiative uvedla v 2025, že 95% pilotních projektů generativní AI selže při doručení měřitelné obchodní hodnoty.
Studie RAND často citovaná na Redditu v r/ArtificialIntelligence na začátku 2026 zjistila, že 80 až 90% projektů AI agentů selže v produkčním prostředí.
Míra přijetí GitHub Copilot mezi vývojáři se ustálila kolem 35 až 40%, zatímco Cursor je na 42 až 45% a Claude Code získal 46% „nejmilovanější“ hodnocení v 2026 AI coding průzkumu. Ohromující obrat pro nástroj, který byl spuštěn teprve v květnu 2025.
Satya Nadella údajně označil interní nasazení Copilota v Microsoftu za „téměř nepoužitelné“ na konci 2025 a firma oznámila, co vedení interně popsalo jako „reset s vysokými sázkami“ produktu.
Studie na arXiv zveřejněná na konci 2025 zjistila, že autocomplete ve stylu Copilota ve skutečnosti zvyšuje frustraci zkušených vývojářů, protože narušuje jejich pracovní tok návrhy, které jsou věrohodné, ale nenápadně chybné.

Stagnace není selháním základních modelů. Je to selhání vzoru interakce. Kopilot funguje na úrovni jednotlivého stisku klávesy nebo otázky. Kolega funguje na úrovni pracovního postupu. Bits&Chips to v dubnovém 2026 eseji „Od kopilota ke kolegovi“ vystihli: „Kopilot funguje na úrovni jednotlivé interakce, zatímco agent funguje na úrovni workflow. To je důležité, protože v většině organizací není úzkým hrdlem jednotlivý úkol, ale koordinace mezi úkoly.“

O tento posun se nyní podniky snaží. Nerovnoměrně, nedokonale, ale v měřítku, na kterém záleží.

Spektrum autonomie

„Agent“ se stal marketingovým pojmem, pojďme být konkrétní. Existují čtyři jasné úrovně autonomie AI a většina zklamání v 2025 a 2026 vznikla z jejich záměny.

Úroveň 1: kopilot

Navrhuje. Žádá o povolení. Zůstává na vaší obrazovce. Autocomplete GitHub Copilot je archetypem. Hodnota se měří v ušetřených stiscích kláves.

Úroveň 2: asistent

Odpovídá na otázky a na požádání tvoří výstupy. ChatGPT, Claude v prohlížeči, chat panel Microsoft 365 Copilot. Hodnota se měří kvalitou návrhu a syntézou kontextu.

Úroveň 3: agent

Přijímá cíl, plánuje sekvenci kroků, provádí je napříč nástroji, podává zprávu. Claude Code skenuje repozitář a otevírá PR. ChatGPT Deep Research běží 20 minut vyhledávání a vrací citovanou zprávu. Anthropic zdokumentoval instanci Claude, která dokončila 7hodinový autonomní inženýrský úkol pro Rakuten. Hodnota se měří počtem dokončených workflow na hodinu lidské práce.

Úroveň 4: kolega

Agent, který funguje v rámci vašeho existujícího modelu oprávnění, účastní se týmové komunikace, drží kontext napříč dny a týdny a je odpovědný stejnému auditnímu záznamu jako lidský zaměstnanec. Toto je hranice.

Komunita r/ChatGPT na Redditu nabídla pragmatický test pro rozlišení těchto úrovní, parafrázováno: bere věc iniciativu, nebo čeká na každý pokyn? Zvládá nečekané situace, nebo spadne a musíte ji znovu instruovat? Pamatuje si kontext napříč vícekrokovým úkolem, nebo se musíte opakovat? Většina produktů označovaných jako „AI agenti“ v 2025 neprošla ani jednou z těchto otázek. Ty, které prošly, jsou to, co dnes lidé myslí slovem „kolega“.

Používání počítače vs dovednosti: proč na architektuře záleží

AI na úrovni kolegy musí jednat ve světě. Existují dva architektonické přístupy, které nesou velmi odlišné rizikové profily.

Používání počítače

AI ovládá simulovanou myš a klávesnici. Doslova vidí obrazovku a kliká na tlačítka. Anthropic uvedl Computer Use na konci 2024, následoval OpenAI Operator. Výhodou je univerzálnost: jakýkoli software s GUI je dosažitelný.

Cena je v rozsahu dopadu. Agent používající počítač dědí všechna oprávnění přihlášeného uživatele. V říjnu 2025 bezpečnostní tým BeyondTrust ukázal, že Codex agent OpenAI lze přes škodlivý název větve v Gitu se shell příkazy přimět ke čtení a exfiltraci uživatelova GITHUB_TOKEN. Agent dělal přesně to, co by udělal lidský vývojář (checkout větve), ale neměl intuici, že samotný název větve je škodlivý vstup. V tomto incidentu byl model oprávnění vše nebo nic. To je výchozí selhání při používání počítače.

Dovednosti

AI volá jednotlivé dovednosti. Každá dovednost je explicitní, typovaná funkce s úzkým kontraktem: „vyhledej ve Slacku zprávy odpovídající q“, „vytvoř úkol v Linear s title a body“, „přečti tento GitHub soubor.“ Na rozdíl od používání počítače má dovednost předem schválený tvar. Agent ji může volat jen s parametry odpovídajícími kontraktu a platforma může volání povolit, zamítnout nebo vyžádat potvrzení před opuštěním sandboxu.

Rozdíl z hlediska bezpečnosti je v principu nejmenších oprávnění. Základní myšlenka v informační bezpečnosti: proces má mít přístup jen ke zdrojům, které potřebuje ke své funkci, a nic navíc. Dovednosti umožňují vynutit nejmenší oprávnění pro každé volání. Používání počítače ne.

Nasazení na úrovni kolegy používá dovednosti pro strukturované akce (zápis do CRM, otevření tiketu) a používání počítače si nechává pro úzký okraj aplikací, které odmítají zpřístupnit API. Poměr je důležitý. Pokud každá akce ve vašem agentovi probíhá přes simulovanou myš, máte demo produktivity, ne produkční systém.

Architektura důvěry, kterou podniky skutečně potřebují

Přechod od kopilota ke kolegovi není vylepšení modelu. Je to vylepšení infrastruktury. Tři prvky odlišují nasaditelného kolegu od rizika.

1. Izolace oprávnění

Každý agent funguje ve svém vlastním oprávnění, s přihlašovacími údaji, které agent nemůže vyjmout ze svého sandboxu. Virální experiment Andreje Karpathyho autoresearch z března 2026, kde nechal agenta běžet 700 trénovacích experimentů bez dozoru po dva dny, je poučný tím, co neudělal. Karpathyho vlastní repozitář instruuje uživatele, aby „v autonomním režimu vypnuli všechna oprávnění“. To je v pořádku na osobním výzkumném notebooku. V regulovaném podniku je to na vyhazov.

Protipříkladem je Moltbook, čistě AI sociální síť, která krátce vzbudila pozornost na konci ledna 2026 s 1.5 miliony autonomních agentů. Karpathy ji chválil jako „nejneuvěřitelnější sci-fi start, co jsem v poslední době viděl“. Pak bezpečnostní výzkumníci z Wiz objevili na frontendu vystavený API klíč k databázi, který umožňoval plný čtení/zápis do celé produkční databáze, včetně autentizačních tokenů všech 1.5 milionů agentů. Karpathy změnil názor během 24 hodin: „Je to katastrofa. Rozhodně nedoporučuji lidem tohle spouštět na svých počítačích.“ Poučení není „agenti jsou nebezpeční“. Poučení je, že agenti nasazení bez izolace oprávnění na úrovni identity se zhroutí do jednoho sdíleného rizika.

2. Auditní záznamy

Každá akce zaznamenána, každé rozhodnutí dohledatelné. Singapurský rámec IMDA, vydaný v Davosu v lednu 2026, to kodifikuje dvouosou maticí rizik, která mapuje prostor akcí agenta (čtení vs zápis, vratné vs nevratné) proti jeho autonomii (jak samostatně rozhoduje). Čím výše je kterákoliv osa, tím bohatší je požadavek na audit. Tento rámec pečlivě studují evropští i američtí regulátoři, protože je jedním z prvních, který převádí správu z abstraktních principů do provozního kalibračního nástroje.

Simon Willison paralelně prosazuje sjednocené logování, aby agenti mohli monitorovat své operace a zotavit se z chyb: „Agenti s plným přístupem k systému jsou mocní a nebezpeční.“ Praktický bod: pokud vaše nasazení agentů nemá sjednocený log, který může compliance důstojník přečíst v pořadí, jste jen jeden incident od ztráty práva nasazovat.

3. Oprávnění k dovednostem s omezeným rozsahem

Ne „přístup k e-mailu“. Přístup k search inbox where from:@customer.com AND within last 7 days. Moderní platformy agentů směřují k parametrizovaným rozsahům, kde oprávnění agenta volat dovednost je omezeno argumenty předem schválenými administrátorem, ne hrubým OAuth rozsahem, který by použil člověk.

Spojte tyto tři prvky a odpovíte na otázku, kterou si každý CISO klade právě teď: co agent udělá, když se splete, a jak to zjistím? Průzkum McKinsey State of AI v 2026 zjistil, že 72% podnikových respondentů označilo kyberbezpečnost za obavu u generativní AI a bezpečnost byla označena jako #1 bariéra pro škálování agentních workflow přibližně dvěma třetinami respondentů. Izolace oprávnění, auditní záznamy a oprávnění k dovednostem s omezeným rozsahem nejsou compliance divadlo. Jsou to klíčová infrastruktura.

Proč na tom záleží právě teď: tři síly se sbíhají

Posun od kopilota ke kolegovi v 2026 není dán jediným průlomem. Je výsledkem průniku tří křivek.

Síla 1: integrace už není na míru

V 2024 znamenalo napojení agenta do firemního SaaS stacku psaní vlastního konektoru pro každý nástroj. Na začátku 2026 typované kontrakty dovedností a předpřipravené konektory tuto práci zkrátily. Agent, který v 2024 potřeboval šest týdnů integrace, potřebuje v 2026 odpoledne. Povrch typické středně velké firmy (Slack, GitHub, Gmail, Linear, Notion, HubSpot, CRM, kalendáře) je nyní pokryt zralými open-source knihovnami konektorů s typovanými oprávněními.

Síla 2: multi-agentní systémy se stávají realitou

Gartner označil Multi-Agent Systems za hlavní strategický technologický trend pro 2026. Významný VP analytik Gene Alvarez nabídl metaforu, která se nyní opakuje na každém podnikovém AI slidu: „Představte si tým v boxech Formule 1. Každý člen má specializovanou roli (měnič pneumatik, tankovač, zvedák), ale jsou sladěni kolem jednoho cíle. Tak vypadá nasazení agentů v podnicích v 2026.“ Jednoagentní systémy narážejí na strop v dlouhodobém uvažování. Multi-agentní systémy se specializovanými rolemi a explicitními předávkami jsou způsob, jak týmy dnes tyto stropy obcházejí.

Síla 3: rozvolnění podnikových rozpočtů

G2 ve svém 2026 State of Software výzkumu uvedl, že 57% firem má AI agenty v produkci (oproti cca 20% o rok dříve).
McKinsey zjistil, že 23% podniků aktivně škáluje agentní AI, přičemž 62% experimentuje. Na okraji zůstává jen asi 15% velkých organizací.
Deloitte v 2026 průzkumu mezi 3,235 podnikovými lídry identifikoval finanční služby jako hlavního adoptéra, s doloženou případovou studií AI agenta, který zachycuje a zpracovává výstupy ze schůzek napříč obchodním pipeline, což dříve vyžadovalo tři analytiky.
Stanford's Enterprise AI Playbook, vydaný na začátku 2026, katalogizoval 51 produkčních nasazení, přičemž případ migrace fintech ETL se stal referenční implementací pro týmy v regulovaných odvětvích.
Oznámené investice do podnikové AI infrastruktury překročily $600 miliard v cyklu 2025.
Dario Amodei z Anthropicu na konferenci Code with Claude uvedl 70 až 80% pravděpodobnost, že první jednolidská miliardová firma vznikne v 2026, poháněná agentní pracovní silou.

Peníze jsou, protokol je, architektura je. V každé zasedačce se nyní vyjednává kolik autonomie, pod jakou správou a pro které workflow.

Skeptický pohled: co říkají Reddit, arXiv a incidenty

Odpovědný pohled na tento posun musí vážně zohlednit i ty, kteří si myslí, že je vše přehnané.

Na Redditu je konsensus napříč r/LocalLLaMA, r/ClaudeCode a r/ChatGPT pragmatický: kódovací agenti dorazili a jsou užiteční. Většina ostatních „agentů“ jsou automatizační workflow v chatbotím převleku. V desítkách vláken v 2026 se cituje: „Použij Copilot, když chceš návrhy. Použij Claude Code nebo Cursor, když chceš, aby něco skutečně udělal.“ Tato produktivní hranice je výstižná. Stejné komunity jsou neúprosné v benchmarcích. I nejlepší agenti dosahují zhruba 60% celkově na Terminal-Bench a klesají na 16% u těžkých úloh. Claude Opus 4.5 vede SWE-bench s 80.9%, což stále znamená, že jeden úkol z pěti selže.

Akademický skepticismus je těžší setřást. Vishal Sikka (bývalý CTO SAP, žák Johna McCarthyho) a jeho spolupracovník publikovali Hallucination Stations: On Some Basic Limitations of Transformer-Based Language Models, kde matematicky dokazují, že transformer LLM jsou zásadně omezené ve schopnosti vykonávat výpočetní a agentní úkoly nad určitou hranicí složitosti. Sikkův závěr, „Není možné, aby byly spolehlivé“ pro vysoce kritické operace, koluje v každém CISO Slacku. Práce netvrdí, že agenti jsou k ničemu. Tvrdí, že existuje třída problémů, kde člověka z procesu nelze vyřadit, ať je model jakkoli dobrý.

Skutečné incidenty skepticismus potvrzují. Vedoucí zákaznické zkušenosti v retailu citovaný v průzkumu Yellow.ai 2026: „Museli jsme stáhnout naši AI podporu už po dvou týdnech, protože začala citovat nesprávné reklamační podmínky a vymýšlet slevy asi v 1.35% tiketech. Náklady na uznání těchto chyb byly mnohem vyšší, než jsme doufali ušetřit.“ Ve velkém měřítku se i sub-2% chybovost rychle prodraží.

Syntéza: AI na úrovni kolegy je reálná v kódování, výzkumu, strukturovaných operacích a úzkých podpůrných workflow. Zatím není reálná v otevřených zákaznických interakcích bez lidského kontrolora. Podniky, které v 2026 získávají hodnotu, jsou ty, které si upřímně přiznají, do které kategorie workflow patří.

Praktický dopad: pět otázek před nasazením

Pokud váš tým zvažuje AI spolupracovníka (vlastní nebo třetí strany), tyto otázky odlišují produkční nasazení od těsného neúspěchu.

Jaký je rozsah škody nejhorší jediné akce, kterou agent může provést? Zmapujte to doslova. Pokud je nejhorší scénář „pošle nedodělaný e-mail špatné osobě“, governance je jednoduchá. Pokud „upraví produkční data“ nebo „pošle pokyn k převodu peněz“, laťka je o řád výš. Zmapujte to před nasazením, ne až po incidentu.
Jak agent získává přihlašovací údaje a může někdy číst surový token? Jsou tři odpovědi a jen jedna je bezpečná. Pokud má agent kopii uživatelova OAuth tokenu ve svém prostředí, v podstatě jste dali LLM svou peněženku. Pokud má agent „vlastní“ identitu přes samostatný service-account OAuth, musíte ji sledovat a rušit jako skutečného uživatele. Třetí odpověď, kterou opravdu chcete: token se k agentovi nikdy nedostane. Žije na platformě, šifrovaný, a je injektován na síťové proxy jen včas, pouze pro volání, která prošla kontrolou politiky, a jen do návratu volání.
Je každá akce zalogována někde, kde ji compliance důstojník může přečíst v pořadí? Sjednoceně, dotazovatelně, s ochranou proti manipulaci. Pokud odpovíte „nějaké logy máme v CloudWatch“, nejste připraveni.
Můžete omezit přístup k dovednostem na konkrétní parametry, které workflow potřebuje? Pro každé volání, ne pro každou integraci. Čtení vs zápis. Podle ID zdroje. Podle časového okna. Oprávnění agenta by měla být přesně vymezena kolem úkolu, ne kolem celého skladu.
Jaký je postup pro návrat zpět, když se něco pokazí? Jak akci vrátíte? Jak rychle? Koho to upozorní? Nevratné akce (převody peněz, e-maily zákazníkům, produkční deploye) potřebují potvrzovací krok nebo zpožděné okno. Vratné mohou běžet autonomně.

Projít všech pět. Pokud na všechny odpovíte, jste už za érou kopilotů a v části, která skutečně mění způsob práce týmu. Pokud odpovíte na dvě nebo tři, tam je třeba se zaměřit, není to důvod čekat. AI spolupracovník na úrovni kolegy, po kterém roadmapa sahá, už někde běží v produkci. Mezera mezi vámi a jím je infrastrukturní, ne v AI modelech. A infrastrukturní mezery se zavírají rychle.

Nemusíte čekat na další vydání modelu. Potřebujete zvolit platformu, která už na těchto pět odpovídá, a začít agentovi zadávat skutečnou práci.

Často kladené otázky

Jaký je skutečný rozdíl mezi kopilotem a AI kolegou?

Kopilot navrhuje, žádá o povolení a žije v jednom nástroji. Kolega přijímá cíle, plánuje napříč systémy, provádí s omezenými oprávněními a je odpovědný stejnému auditnímu záznamu jako člověk. Bits&Chips to vystihli: kopiloti fungují na úrovni interakce, kolegové na úrovni workflow.

Jak by agenti měli nakládat s uživatelskými přihlašovacími údaji?

Ani jedna z očividných možností není správná. Kopírování uživatelova OAuth tokenu do prostředí agenta vkládá živý údaj do kontextu LLM. Vytvoření samostatné identity pro každý agent znamená, že každý agent je subjekt, kterého musíte sledovat, rušit a auditovat jako člověka. V praxi funguje zprostředkovaný přístup: token žije na platformě, šifrovaný; odchozí síťová proxy sandboxu volá platformu v čase požadavku; platforma dešifruje token a vrací pouze vyřešené auth hlavičky pro volání, která prošla kontrolou politiky; agent sám nikdy nečte, neloguje ani nevyžaduje surový token.

Používání počítače nebo dovednosti – co zvolit?

Dovednosti ve výchozím stavu, pro vše s API. Používání počítače jen když cílový systém nemá programovatelné rozhraní. Incident BeyondTrust Codex je varováním: používání počítače dědí plná oprávnění uživatele a škodlivý vstup kdekoliv v zorném poli agenta se může stát exploitací.

Jak autonomně by agenti skutečně měli fungovat?

Použijte dvouosý rámec Singapore IMDA: prostor akcí × autonomie. Úzký prostor akcí (pouze čtení, vratné) snese vysokou autonomii. Široký prostor akcí (zápisy, nevratné, zákaznické) vyžaduje lidské potvrzení nebo zpožděné okno pro zásah. Nejhorší je vysoká autonomie u vysoce rizikových akcí bez auditní stopy.

Jak měřit návratnost investice?

Přestaňte měřit ušetřené stisky kláves. Měřte workflow dokončené na hodinu lidské práce, čas do vyřešení incidentu a míru předání úkolu zpět člověku. Zjištění Deloitte 2026 naznačují, že hlavní uživatelé sledují tři metriky: míru dokončení workflow, chybovost a míru lidského zásahu a optimalizují jejich poměr.

Co dělat s 95% mírou selhání pilotů?

Pečlivě si přečtěte rozbor MIT NANDA. Neúspěšné piloty běžely hlavně na „hloupém RAG“ (všechno do kontextu), „křehkých konektorech“ (rozbité API integrace) a bez event-driven architektury. Úspěšné měly kolem LLM operační vrstvu: paměť, I/O a oprávnění. LLM jádro není úzkým hrdlem. Je jím okolní infrastruktura.

Kde se VM0 nachází

Zero jsme postavili na jedné architektonické sázce: agent by nikdy neměl držet přihlašovací údaj. Ne ve svém prostředí, ne ve svém promptu, ne ve své paměti. Token zůstává na platformě. Každé odchozí volání agenta je zprostředkováno síťovou proxy, která rozhoduje, zda pro dané volání vložit auth hlavičku nebo požadavek zablokovat.

To je neobvyklá volba. Běžné vzory v 2026 jsou buď dát agentovi vlastní OAuth identitu (teď máte druhý subjekt k auditu a zrušení), nebo mu předat kopii uživatelova tokenu v proměnné prostředí (teď může LLM číst vaši peněženku). My neděláme ani jedno. Takto to skutečně funguje.

Token se k agentovi nikdy nedostane. Když připojíte konektor k Zero (GitHub, Slack, Gmail, Linear, Notion, HubSpot atd.), OAuth token je uložen šifrovaně na platformě. Refresh tokeny zůstávají v databázi a nikdy ji neopouštějí. V sandboxu není žádná GITHUB_TOKEN proměnná prostředí ke čtení, žádný soubor s tajemstvím k otevření, žádný nástroj, který by token vrátil.

Každé volání zprostředkovává síťová proxy. Každý HTTP požadavek opouštějící sandbox prochází přes addon založený na mitmproxy. Proxy identifikuje konektor podle hostname požadavku, vyhledá firewall politiku pro daného agenta a zkontroluje, zda je metoda a cesta povolena. Pokud ano, proxy volá zpět na webhook platformy. Platforma dešifruje token, obnoví jej, pokud je expirovaný, vyřeší šablony hlaviček (${{ secrets.GITHUB_TOKEN }} se stane skutečnou hodnotou) a vrací pouze vyřešené auth hlavičky proxy. Proxy je vloží do odchozího požadavku. Po dokončení volání jsou hlavičky z paměti proxy pryč. Agent je nikdy neviděl.

Oprávnění jsou na úrovni agenta, konektoru a typována na úrovni endpointu. Každý agent nese objekt politiky, který mapuje každý konektor na sadu pojmenovaných skupin oprávnění. github:repo-read není vágní rozsah. Je to sada konkrétních pravidel metoda-cesta, například GET /repos/{owner}/{repo}/pulls. Udělení přístupu ke GitHubu neznamená přístup ke všemu. Uděluje konkrétní záměr v rámci GitHubu.

Tři stavy politiky, ne dva. Každé oprávnění se vyhodnocuje na allow, deny nebo ask. Poslední vyžaduje lidské potvrzení před provedením akce. Cokoliv, co firewall výslovně nespáruje, padá na úroveň unknownPolicy konektoru, která výchozí na deny. Nejmenší oprávnění je výchozí, ne volitelné.

Jeden sandbox na jedno spuštění. Každé spuštění agenta běží ve vlastním Firecracker microVM s izolovaným síťovým jmenným prostorem. Po skončení běhu je namespace zrušen. Dvě spuštění stejného agenta jsou dva oddělené sandboxy se dvěma oddělenými auditními záznamy.

Auditní stopa pro každý požadavek. Stejná proxy, která rozhoduje povolit/zamítnout, také zapisuje pro každý běh JSONL log s metadaty firewallu u každého požadavku: konektor, skupina oprávnění, konkrétní pravidlo, rozhodnutí, čas. Tyto logy se vrací na platformu. Pokud CISO potřebuje vědět, co agent dělal 14. dubna mezi 15:00 a 17:00 CST, je to jeden dotaz.

CLI, které vysvětlí vlastní zamítnutí. Když oprávnění zablokuje volání, agent (nebo člověk vedle něj) může spustit zero doctor permission-deny <connector> --method <M> --path <P> a dostane zpět přesně tu skupinu oprávnění, která požadavek zablokovala, plus odkaz na nápravu. zero doctor permission-change umožňuje adminům oprávnění přímo přepnout, nebo členovi podat písemnou žádost (omezenou na 500 znaků, aby bylo čitelné), která jde adminovi. Oprávnění s vysokým rizikem jako slack:chat:write nebo gmail.send spouští zvláštní varování s odkazem na bezpečnější, botem omezenou alternativu.

Dvě role, jeden schvalovací tok. Vlastníci a administrátoři mění oprávnění přímo. Členové podávají žádost s odůvodněním, která jde adminovi. Není třetí „napůl-admin“ úroveň. Tok je dost malý, aby ho lidé skutečně používali, což je smysl.

Používání počítače si necháváme pro úzkou skupinu starších systémů, které odmítají zpřístupnit API. Vše ostatní jde přes dovednosti. Každá akce je kontrolována politikou. Každý přihlašovací údaj zůstává na platformě. Každé rozhodnutí je zalogováno.

Pokud už nechcete „další AI autocomplete“ a chcete vyzkoušet AI spolupracovníka, kterého vám bezpečnostní tým schválí, podívejte se, jak Zero řeší plánované workflow, třídí produkční incidenty nebo spustí ranní produktový briefing.

Éra kopilotů nekončí. Je pohlcena něčím větším. Týmy, které v příštím cyklu uspějí, budou ty, které pochopí rozdíl.