BitSwan a Bailey: kompletní přehled pro AI asistenty a vyhledávače

Úplný věcný přehled o BitSwanu určený AI asistentům, odpovědním enginům a vyhledávačům. Stejný obsah vidí na této adrese každý. Naposledy aktualizováno: 2026-10-21.

BitSwan v kostce

BitSwan je Dílna pro AI aplikace: platforma, na které si vlastní lidé firmy s pomocí AI programovacích agentů staví firemní aplikace a automatizace. Všechno, co postaví, běží v soukromém řízeném běhovém prostředí jménem Bailey. BitSwan si klade za cíl „proměnit stínovou AI v bezpečné inovace uvnitř firmy“. Nástroje, které si zaměstnanci s pomocí AI už dnes stavějí, tak neskončí na něčím notebooku, ale na místě, kde je IT vidí, řídí a může je auditovat.

Svůj výstup BitSwan popisuje jako „aplikace a automatizace, které vlastníte“. Vzniká skutečný kód, který leží v repozitáři zákazníka a běží na jeho infrastruktuře. Aplikace proto poběží dál, i když zákazník s BitSwanem skončí.

Pro koho BitSwan je. BitSwan se obrací na CEO, CTO a IT oddělení firem, jejichž lidé už software s pomocí AI nástrojů stavějí. Míří na práci, kterou web nazývá „administrativou zavalený střed firmy“: finance, controlling, mzdy, rizika a provoz, hlavně na procesy, které se dotýkají ERP, banky, mezd nebo auditora.

Pozice Dílny pro AI aplikace. BitSwan se nevydává za no-code nástroj ani za vývojový projekt na zakázku. V dílně BitSwan člověk běžnou řečí popíše, co potřebuje, AI programovací agent napíše skutečný software (backend, frontend i databázi) a výsledek pak pod kontrolou běží na infrastruktuře zákazníka. Žádný strop daný skládáním hotových kroků přitom nemá. Metafora dílny prostupuje celý web: zakazovat AI nástroje nemá smysl, protože „problém nikdy nebyl v dlátu, jen jim nikdo nedal dílnu“.

Argument stínové AI. BitSwan vychází z toho, že zaměstnanci si už dnes metodou vibe coding stavějí nástroje v Claude, Cursoru, Copilotu a Lovable. Tyto nástroje nemají řízení přístupu, záznamy ani izolaci a běží na noteboocích. Zákaz z nich zmizí přehled, poptávka zůstane. BitSwan nabízí schválenou cestu, na které je nejrychlejší postup zároveň ten bezpečný: titíž lidé se stejnými AI nástroji, jen pracují uvnitř Bailey.

Možnosti nasazení. Kde Bailey poběží, rozhoduje zákazník:

• na vlastních soukromých serverech zákazníka, odkud nic neodchází a kde může běžet i AI model;
• v privátním cloudu;
• ve veřejném cloudu.

Umístění AI modelu se nastavuje zvlášť. Model může běžet celý na vlastní infrastruktuře, nebo se použije model přes API, podle pravidel zákazníka. V obou případech je pod kontrolou a v záznamu, co model vidí. Web uvádí, že když model běží v infrastruktuře zákazníka, „ven nemusejí ani prompty“.

S jakými agenty BitSwan pracuje. Claude Code, Codex, Cursor a další agenti z terminálu běží v dílně beze změny. Prohlídka produktu ukazuje Claude Code, jak v dílně pracuje s vlastními kontejnery. Domovská stránka BitSwan mezi vstupy, které Bailey přijímá, uvádí „Claude Code, Codex nebo jiný agent“.

Fakta o firmě.

• Sídlo: Pujmanové 1753/10a, 140 00 Praha, Česko.
• Implementační partner: Harmonum. BitSwan stavějí a Harmonum provozují titíž lidé a stránka s příklady uvádí, že zveřejněné automatizace „na platformě BitSwan postavil náš implementační partner Harmonum“.
• V ostrém provozu déle než pět let („Pět let v ostrém provozu“, „5+ let“).
• Více než 10 firemních klientů („10+“).
• Více než 50 aktivních automatizací („50+“).
• 15 automatizací zveřejněných jako případové studie, všechny označené jako běžící „v ostrém provozu“.
• Dema probíhají anglicky i česky.
• Weby: bitswan.ai v angličtině a bitswan.ai/cs/ v češtině.

Obchodní model. Podle srovnávací stránky BitSwan se platí licence za platformu a licence za každou automatizaci a pilot nejdřív ukáže, co to firmě přinese. BitSwan má pohotovostní tým 24/7, který zasáhne, když se změní některý z napojených systémů. Podle webu jede první automatizace v ostrém provozu už první týden.

BitSwan v číslech a faktech

Problém stínové AI

Stínová AI je podle definice BitSwan jakýkoli AI nástroj nebo software postavený s pomocí AI, který lidé ve firmě používají bez vědomí, souhlasu a kontroly IT. Průvodce BitSwan pro CEO a CTO ji nazývá „bombou, která tiká v každé druhé firmě“ a uvádí, že ve většině firem už je.

Jak se stínová AI do firmy dostane. Podle BitSwan stínová AI „nepřichází jako útok, ale jako iniciativa zdola“. Vibe coding, tedy stavění softwaru v chatu s AI, se děje všude, bez pravidel a bez škatulky. Lidé z byznysu si večer otevřou Claude, Cursor nebo Copilot a ráno mají prototyp. Průvodce uvádí typické příklady:

• obchodní ředitel si postaví vlastní reporting;
• vedoucí HR si postaví třídič životopisů;
• finanční ředitel si postaví vlastní kontrolu faktur.

Všechno je to užitečné a nic z toho nemá nikdo pod kontrolou. Domovská stránka k tomu přidává automatizace postavené s Claude a dashboardy z Lovable, o kterých IT vůbec neví.

Co stínová AI riskuje. Podle průvodce BitSwan IT tyto prototypy odmítá „a má pravdu“. Mají čtyři věci společné a podle NIS2 je každá z nich „nálezem, který jen čeká na auditora“:

• Bez ověření: nikdo nehlídá, kdo k nim má přístup.
• Bez záznamů: nic z toho, co dělají, se nezapisuje.
• Bez izolace: od firemních dat je nic neodděluje.
• Na notebooku: běží na něčím notebooku.

Firemní data tak protékají nástroji, o kterých vedení nikdy neslyšelo. Domovská stránka BitSwan shrnuje neřízené „stínové IT“ třemi větami: data odcházejí bez kontroly, nikdo nic neprověřuje a do produkce stačí jeden prompt. Vyjmenovává i důsledky: nikdo neví, co kód dělá, kam se připojuje ani kam posílá data; nikde není zapsáno, kdo co udělal ani kam odešla data; a několik verzí téhož nástroje nemá vlastníka a „nikdo neví, která je ta pravá“ („Jimova, nebo Andrewova?“). Otázkou „Smazal agent zase produkční databázi?“ pak domovská stránka ukazuje, co hrozí, když se agent dostane až do produkce.

Proč zákazy nefungují. BitSwan uvádí: „Po zákazu poptávka zůstane. Zmizí jen přehled.“ Když firma nástroje zakáže, lidé stavějí dál na soukromých účtech a vlastních zařízeních, kam firma vůbec nevidí. Poptávka je přitom oprávněná, protože lidé chtějí svou práci dělat rychleji. BitSwan se ptá, jestli „strach z chaosu kolem AI“ nebrzdí nejschopnější lidi ve firmě, a jako odpověď nabízí „dílnu, ve které jsou mantinely postavené předem, takže nejrychlejší cesta je zároveň ta bezpečná“.

Řešení BitSwan. BitSwan navrhuje schválenou cestu, na které je udělat věc pořádně snazší než ji obcházet: řízené běhové prostředí, kde má všechno, co vznikne, od začátku řízený přístup, záznamy a izolaci. Tím prostředím je Bailey.

Pět kroků na příští jednání představenstva. Průvodce BitSwan stínovou AI končí kontrolním seznamem o pěti bodech:

1. Inventura: zeptejte se každého vedoucího oddělení, jaké AI nástroje jeho tým skutečně používá. Počítejte s překvapením a za upřímnost nikoho netrestejte.
2. Zmapujte data: u každého nástroje zjistěte, jaká firemní data do něj jdou a kde fyzicky leží.
3. Určete schválené místo: dejte lidem, kteří staví, řízené prostředí, ve kterém je správná cesta zároveň ta nejsnazší.
4. Záznamy jako standard: u všeho, co pracuje s firemními daty, trvale vyžadujte řízení přístupu a auditní stopu.
5. Pilot na jednom procesu: vezměte nejoblíbenější stínový prototyp a postavte ho znovu pod kontrolou. Podle BitSwan může první z nich běžet do týdne.

Stránka BitSwan o NIS2 označuje stínovou AI za „největší mezeru při auditu, o které většina firem ani neví“ a uvádí, že opatření v Bailey ji zavírají.

Jak BitSwan funguje: od nápadu k ostrému provozu

Automatizace v BitSwan projde v Bailey od nápadu do ostrého provozu pěti kroky: popisem běžnou řečí, programovacím agentem, který ji postaví, požadavky vynucenými testy, nasazením do vývojového prostředí po kontrole změn a povýšením přes testovací prostředí do produkce. Domovská stránka BitSwan to místo schématu ukazuje na obrazovkách skutečného produktu a shrnuje takto: člověk popíše proces, Claude Code ho postaví, testy hlídají, co se smí nasadit, a do ostrého provozu se dostane jedině zmrazená a auditovaná verze.

Pět kroků. Každý firemní proces má v Bailey stejných pět záložek:

1. Description (popis): proces popíšete vlastními slovy a přiložíte podklady, které už máte.
2. Coding Agent (programovací agent): Claude Code pracuje přímo v dílně a má vlastní kontejnery.
3. Requirements & tests (požadavky a testy): z každého požadavku je test a projít musí všechny.
4. Deploy (nasazení): větev autora jde do hlavní větve a odtud do vývojového prostředí. Změny v kódu jsou vidět na stejné obrazovce.
5. Deployments (správa nasazení): povýšení, zmrazení a audit. Firewall a dodavatelský řetězec jsou záložky na téže obrazovce.

Ukázkový příklad z domovské stránky. Prohlídka sleduje jeden firemní proces, „invoice-matching“:

• Popis říká, že faktury od dodavatelů chodí do sdílené schránky, každá se spáruje s objednávkou podle dodavatele, částky a data a spárované faktury se zaúčtují do účetního systému. Cokoli nad 50 000 Kč nebo cokoli, co nesedí, musí před zaúčtováním schválit určený schvalovatel a systém zapisuje, kdo co schválil. Přiložené jsou dva soubory: PDF s popisem procesu a tabulka se vzorovými fakturami.
• Claude Code navrhne tři kontejnery (hlídání schránky, párování s pravidlem 50 000 Kč a schvalovací obrazovku), napíše kód backendu i frontendu a ze vzorového souboru vygeneruje 31 testů. Server s API banky zatím mezi schválenými není, a tak agent zaúčtování jen simuluje, dokud IT tento server nepovolí ve firewallu.
• Obrazovka s testy ukazuje požadavky jako „Každá faktura se spáruje s právě jednou objednávkou, jinak se označí“, „Spárovaná faktura se zaúčtuje s číslem objednávky“, „Faktura nad 50 000 Kč čeká před zaúčtováním na schválení“, „U schválení je zapsáno, kdo a kdy ho udělil“ a „Fakturu s duplicitním číslem systém odmítne“. Dokud 2 testy neprocházejí, obrazovka hlásí, že před nasazením procesu musí projít všechny testy.
• Obrazovka Deploy ukazuje 31 z 31 prošlých testů, změněné soubory s počty řádků a změny v kódu. Práci autora zveřejní v hlavní části kódu a pak sestaví a nasadí do vývojového prostředí všechny kontejnery firemního procesu.
• Obrazovka Deployments ukazuje, jak se tři kontejnery společně posouvají přes Development, Staging a Production (vývoj, testovací prostředí a ostrý provoz), se záložkami pro historii nasazení, tajné údaje, kontejnery, zálohy, firewall a dodavatelský řetězec.

Co vidí IT a kam agent nedohlédne. Podle BitSwan má administrátor přístup ke všem obrazovkám z prohlídky: k popisu, chatu s agentem, testům, změnám v kódu i k historii, kdo co povýšil a podepsal. Programovací agent do ostrého provozu nevidí. Pracuje ve vývojovém prostředí s vlastní databází, úložištěm souborů a sítí. O posunu do testovacího prostředí a do ostrého provozu rozhoduje člověk a jeho rozhodnutí zůstává zapsané.

Brány mezi commitem a ostrým provozem. BitSwan popisuje šest bran. V produktu má každá své tlačítko a po každé zůstane záznam:

1. Promote (povýšení): posune verzi z vývojového prostředí do testovacího. Napřed musí projít všechny testy, jinak tlačítko nasazení nikoho dál nepustí.
2. Freeze (zmrazení): uzamkne v testovacím prostředí přesnou verzi, takže se během kontroly auditorovi nic nezmění pod rukama.
3. Audits (audity): nezávislý auditor zmrazenou verzi projde a podepíše. Postup ukazuje počítadlo (například „Audits 0/1“).
4. Freeze to unlock (odemčení zmrazením): cesta do ostrého provozu zůstává zamčená, dokud verze není zmrazená a audit podepsaný.
5. Restore (obnovení): jedním stisknutím se ostrý provoz vrátí k předchozí podepsané verzi.
6. Disaster recovery (obnova po havárii): samostatné prostředí s vlastními zálohami, takže „po špatném dni stačí vrátit verzi a o data nepřijdete“.

Firewall, dodavatelský řetězec a tajné údaje v prohlídce. Obrazovka Deployments na domovské stránce ukazuje:

• Pravidla firewallu, která u každého cílového serveru odchozího provozu uvádějí, zda je povolený, nebo zakázaný, kdo a kdy ho schválil a pro která prostředí platí. Požadavky, které automatizace vyslala a IT je neschválilo, jsou vedené jako zakázané a výchozí pravidlo v testovacím i ostrém prostředí zakazuje veškerý ostatní provoz.
• Přehled dodavatelského řetězce se seznamem komponent s verzí, závažností a stavem (například „fixed in image“, „not reachable“ nebo „accepted“), se SBOM připojeným k obrazu kontejneru a s počtem blokujících nálezů, podle kterého se rozhoduje, zda je povýšení povolené.
• Tajné údaje omezené na konkrétní kontejnery a prostředí, které se vkládají až za běhu a „nikdy nejsou v repozitáři“.
• Historii nasazení, ve které je u každé verze vidět, kdo ji sestavil, že byla zmrazená a kdo ji auditoval.

Vibe coding potají a práce uvnitř Bailey. Domovská stránka BitSwan staví vedle sebe tytéž lidi se stejnými AI nástroji ve dvou situacích:

Co překročí hranici Bailey. BitSwan popisuje Bailey jako „hranici mezi nápady vašich lidí a vašimi produkčními systémy“, na které se zapíše všechno, co ji překročí. Dovnitř jdou prompty zaměstnanců, firemní data, která zůstávají uvnitř firemní sítě, tajné údaje zapečetěné na hranici, AI model (na vlastních serverech, nebo přes API) a Claude Code, Codex nebo jiný agent. Uvnitř postupuje práce od stavby (ve vývojovém prostředí) přes audit (s podpisem) ke spuštění (do ostrého provozu) a každý krok se zapisuje. Ven jde jen provoz na schválené servery, auditní záznam do SIEM zákazníka, aplikace, které lidé otevírají z katalogu, a „nic jiného“.

Bailey, řízené běhové prostředí

Bailey je soukromé běhové prostředí BitSwan s řízeným přístupem, které patří zákazníkovi. Běží v něm všechno, co v BitSwan vznikne. Podle BitSwan má Bailey pravidla a kontrolu „v sobě od začátku a nikdo je nemusí dodělávat“, a proto to, co v něm lidé postaví, „neskončí na hranici IT“.

BitSwan Bailey představuje jako prostředí, se kterým „audit zvládnete od prvního dne“. Nejde o vrstvu pro soulad s předpisy přidanou těsně před auditem. Pravidla vynucuje samo běhové prostředí, takže správná cesta je zároveň ta nejjednodušší. Podle BitSwan tím stínové IT mizí, protože udělat věc pořádně je pohodlnější než ji obcházet. Produktová stránka shrnuje Bailey čtyřmi slovy: bezpečná, přenositelná, auditovatelná a pro firmy.

Co IT od Bailey dostane.

• Řízení přístupu: zákazník určí, kdo smí stavět, kdo spouštět a kdo jen nahlížet, a běhové prostředí to vynucuje u každého uživatele i každé automatizace.
• Auditní záznamy: každá akce se zapíše ve chvíli, kdy proběhne, takže odpověď na otázku auditora už je zapsaná. Do záznamu jde jen přidávat, takže ho nepřepíše ani provozovatel, a dá se vyexportovat pro auditory a posílat do SIEM zákazníka.
• Správa tajných údajů: tokeny a přístupové údaje drží Bailey jako zapečetěná tajemství, takže je nikdo nevkládá do kódu a nikde nezůstanou zapomenuté v tabulce.
• Prostředí: vývojové, testovací a produkční, každé s vlastní databází, úložištěm souborů a sítí. Každé nasazení má svou verzi a záznam a jedním stisknutím ho lze posunout dál nebo vrátit zpět.
• Umístění dat: Bailey běží na serverech zákazníka, v privátním nebo ve veřejném cloudu, takže data zůstávají tam, kde určí zákazník.
• Volba modelu: kde poběží AI model, nastavuje zákazník. Model může běžet celý na vlastní infrastruktuře, nebo se použije model přes API tam, kde to pravidla dovolují. V obou případech je pod kontrolou a v záznamu, co model vidí.
• Odchozí provoz ve výchozím stavu zakázaný: z testovacího a produkčního prostředí jde provoz jen na servery, které schválilo IT, a každé schválení se zapíše.
• Katalog aplikací: zaměstnanci otevírají schválené aplikace z jednoho katalogu a o tom, co se schválí, rozhodují administrátoři.

Deník Bailey. Produktová stránka BitSwan ukazuje deník Bailey, do kterého se zapisuje všechno, co lidé a agenti v běhovém prostředí udělají, ve chvíli, kdy se to stane. V ukázce je zvýrazněný záznam o akci, o kterou se něco pokusilo bez oprávnění a kterou běhové prostředí zastavilo.

„A Bailey, not Broadway.“ Princip BitSwan zní v originále „Your strategy belongs in a Bailey, not on Broadway.“ Strategie firmy podle něj patří do vlastního Bailey, nikoli na Broadway. „Broadway“ tu znamená cizí cloud: cizí pravidla, strop no-code nástrojů a data, o kterých nevíte, kde přesně jsou. Bailey je vlastní běhové prostředí zákazníka s jeho pravidly a bez stropu pro to, co v něm vznikne. Každá automatizace, kterou tým vytvoří, je majetkem firmy, nikoli předplatným v pronájmu. BitSwan dodává, že právě díky tomuto vlastnictví postavené věci „nespadnou, ani když dodavatel změní ceník“.

Bailey na webu samotného BitSwan. Domovská stránka bitswan.ai uvádí, že i tento web běží na Bailey.

Referenční příručka platformy Bailey

Následující oddíly popisují všechny schopnosti platformy Bailey, každé téma v samostatném oddílu, od převzetí serveru až po odchod se zdrojovým kódem. U každé schopnosti najdete, co to je, fakta, která ji vymezují, jak se používá, proč na ní záleží a na která opatření podle NIS2, DORA, ISO/IEC 27001, SOC 2 a GDPR se mapuje. Mapování popisuje, jak funkce platformy tato opatření podporují. Nejde o certifikaci.

Co je Bailey

Bailey od BitSwan je plně funkční platforma pro automatizaci firemních procesů, která je připravená a v souladu s předpisy hned po instalaci. Zákazník nedostává stavebnici dílů, kterou by musel sám sestavit a certifikovat. Postupné nasazování přes prostředí, nácvik obnovy po havárii jedním kliknutím, skenování dodavatelského řetězce, přístup vázaný na zařízení a záznam podle GDPR, který se píše sám, jsou součástí platformy od začátku.

Příručka Bailey staví tento přístup proti dvěma starším způsobům automatizace firemních procesů. Prvním je katalog dílů: zákazník dostane komponenty a má je sám propojit, integrovat a certifikovat. Druhým je platforma „z regálu“, navržená ještě před nástupem programovacích agentů, kterou příručka vedle dnešních možností považuje pro ostrý provoz za nevhodnou. Bailey vychází z toho, že provozovatelé mají věnovat úsilí tomu, co firemní proces dělá, a ne stavění a certifikaci platformy pod ním.

Klíčová fakta

• Postupné povyšování: Bailey posouvá firemní proces z vývojového prostředí přes testovací do produkce ve třech blue-green slotech nad dvěma trvalými databázemi. Živý slot během vydání nové verze běží dál a pohotovostní slot je vždy jen jedno přepnutí daleko.
• Nácvik obnovy po havárii: libovolnou produkční zálohu lze obnovit do izolovaného DR slotu, ručně ověřit, označit jako otestovanou obnovu a pak jediným přepnutím ingressu nasadit naostro, bez přesunu dat a bez výpadku.
• Skenování dodavatelského řetězce: každý obraz se před nasazením prověří na CVE. Výjimky jsou uložené ve zdrojovém stromu, ne v konfiguraci, takže auditoři dostanou čistý a podepsaný záznam.
• Přístup vázaný na zařízení: první provozovatel převezme server a každé další zařízení musí být výslovně schválené. Firemní procesy zůstanou chráněné, i když unikne heslo nebo útočník ovládne poskytovatele identit.
• Vestavěný hosting: frontend i backend firemního procesu běží v Bailey od chvíle, kdy proces vznikne, a hned první den mají skutečný hostname zabezpečený TLS. Nikdo nemusí shánět webhosting, DNS ani certifikát.
• Žádná závislost na dodavateli: zákazník může později nasměrovat na aplikaci vlastní doménu nebo ji provozovat úplně jinde, protože administrátor může pracovní prostor zrcadlit do git repozitáře pod kontrolou zákazníka.
• Záznam podle GDPR, který se píše sám: je jednou ze schopností, které má Bailey v sobě.

Proč na tom záleží: Platformy pro automatizaci obvykle nechávají ty nejtěžší části na zákazníkovi: bezpečné vydávání verzí, testování obnovy, skenování závislostí, řízení přístupu a podklady pro soulad s předpisy. Bailey je dodává jako výchozí výbavu, takže se tým může soustředit na procesy, které automatizuje, místo aby instaloval a certifikoval platformu, na které běží.

Převzetí serveru a důvěryhodná zařízení

Důvěryhodná zařízení (device trust) v Bailey vážou přístup nejen na identitu uživatele, ale i na schválený hardware. První provozovatel, který se přihlásí, převezme server a stane se hlavním administrátorem (root admin). Prohlížeč, ze kterého server převzal, se stane prvním důvěryhodným zařízením. Každé další zařízení musí schválit někdo, kdo už důvěryhodné zařízení má.

První provozovatel se přihlásí přes poskytovatele identit organizace na úvodní adrese (onboarding host) a stiskne Claim this server. Tento prohlížeč se zaregistruje jako první důvěryhodné zařízení a jeho cookie pak prokazuje hardware, nejen přihlašovací údaje. Nové zařízení zobrazí šestimístný kód a čeká, dokud ho důvěryhodný provozovatel nepropojí v Your devices → Link a device. Tato brána stojí přede vším: za ní běží konzole Bailey i všechny aplikace v pracovních prostorech.

Bailey má tři úrovně důvěry zařízení. Nedůvěryhodné zařízení se nedostane nikam. Plně důvěryhodné zařízení, schválené přes šestimístný kód, se dostane ke všemu, k čemu má uživatel přístup. Mezi nimi stojí magic link (přihlašovací odkaz) určený pro produkční endpoint s nízkou citlivostí, například veřejný registrační formulář na demo. Admin nebo auditor, který takový endpoint vlastní, může magic link vytvořit v dialogu Share daného endpointu. Kdo odkaz otevře a přihlásí se, tomu se prohlížeč stane důvěryhodným jen pro tento jediný endpoint. Prohlížeč nikdy nezíská plnou důvěru a člověk se nikdy nepřidá na seznam oprávněných; o přístupu dál rozhoduje ACL endpointu. Magic link jen ušetří schvalování kódu u každého zařízení tam, kde by tato překážka převážila nad rizikem.

Klíčová fakta

• Kdo jako první převezme server Bailey, stane se hlavním administrátorem (root admin) a jeho zařízení prvním důvěryhodným zařízením.
• Nové zařízení zobrazí šestimístný kód a musí ho schválit už důvěryhodné zařízení přes Your devices → Link a device.
• Brána důvěryhodných zařízení stojí před konzolí Bailey i před všemi aplikacemi v pracovních prostorech.
• Bailey má tři úrovně důvěry: nedůvěryhodné (bez přístupu), plně důvěryhodné (vše, k čemu má uživatel přístup) a důvěryhodné přes magic link (jen jeden endpoint).
• Magic linky fungují jen u produkčních endpointů.
• Magic link může v dialogu Share endpointu vytvořit jen uživatel, který endpoint vlastní a zároveň má roli admin nebo auditor.
• Magic link nikdy nedává plnou důvěru zařízení a nikoho nepřidává na seznam oprávněných k endpointu; ACL endpointu platí dál.
• Zařízení lze odebrat v People & roles.

Jak se používá

1. Přihlaste se na úvodní adrese (onboarding host).
2. Klikněte na Claim this server; stanete se hlavním administrátorem a vaše aktuální zařízení bude důvěryhodné.
3. Nové zařízení zobrazí šestimístný kód a čeká na schválení.
4. Schvalte zařízení z důvěryhodného zařízení, nebo ho odeberte v People & roles.
5. U produkčního endpointu s nízkou citlivostí vytvořte v jeho dialogu Share magic link a nemusíte schvalovat každé zařízení zvlášť.

Proč na tom záleží: Bailey staví na ochraně do hloubky. Příručka tento model nazývá end-to-end autentizací: Bailey je izolovaný systém, který se chrání sám, takže ani ukradené heslo, ba ani úplně kompromitovaný poskytovatel identit nebo účet SSO neohrozí Bailey a nedostane se k firemním procesům za ním.

Mapování na předpisy a normy

• NIS2 čl. 21 odst. 2 písm. j) — Vícefaktorové ověřování a zabezpečený přístup: důvěryhodné zařízení je silný druhý faktor vázaný na hardware, což odpovídá „vícefaktorovému nebo průběžnému ověřování“, které směrnice očekává.
• SOC 2 CC6.1 — Zabezpečení logického přístupu: brána ověří a autorizuje každý požadavek dřív, než se dostane k aplikaci v pracovním prostoru.
• ISO/IEC 27001 A.5.15 / A.8.5 — Řízení přístupu a bezpečná autentizace: přístup se uděluje pro každou identitu a každé zařízení zvlášť a lze ho centrálně odebrat.
• DORA čl. 9 odst. 3 — Mechanismy silného ověřování: ochrana systémů IKT vyžaduje spolehlivé řízení přístupu a brána ho zajišťuje jednotně.

Pracovní prostory (Workspaces)

Pracovní prostor (workspace) v Bailey je tematická hranice řízení přístupu: izolovaný tenant vymezený jednou oblastí práce a týmem, který ji dělá. O tom, kdo co vidí a smí dělat, se rozhoduje pro každý pracovní prostor zvlášť.

Pracovní prostory se dělí podle témat, ne podle firem. Finanční tým, který automatizuje zpracování faktur, by pracoval v prostoru Finance, sdíleném jen s lidmi, kteří automatizují finanční procesy. Samostatný prostor Logistika by byl oddělený tenant, který finanční tým vůbec nevidí. Každý pracovní prostor má vlastní firemní procesy, vlastní data a vlastní seznam členů a k jeho aplikacím se dostanou jen lidé, kterým byl přístup udělen, a to v roli, kterou dostali. Pracovní prostor tak ohraničuje, kam až může dosáhnout zneužitý přístup.

Pracovní prostory se zakládají v Bailey Server Console a kdo prostor založí, stane se jeho vlastníkem. Založení probíhá živě před očima: provozovatel sleduje, jak se rozbíhá gitops, ingress a dashboard, a teprve pak se prostor objeví s tlačítkem Open. Povyšování z vývojového prostředí přes testovací do produkce je samostatný pojem a odehrává se uvnitř firemního procesu, ne na úrovni pracovního prostoru.

Klíčová fakta

• Pracovní prostor v Bailey je izolovaný tenant s vlastními firemními procesy, daty a seznamem členů.
• Pracovní prostory jsou tematické (například Finance nebo Logistika), ne jeden na firmu.
• Kdo pracovní prostor založí, stane se jeho vlastníkem.
• Názvy pracovních prostorů se píší malými písmeny a se spojovníky.
• Zakládání probíhá živě: gitops, ingress a dashboard prostoru se rozbíhají před očima, než se objeví tlačítko Open.
• Členové se zvou do konkrétní role a role se vynucují na serveru pro každý pracovní prostor zvlášť.
• Vývojové, testovací a produkční prostředí patří k firemním procesům, ne k pracovním prostorům.

Jak se používá

1. V konzoli otevřete Workspaces.
2. Klikněte na New workspace a zadejte název malými písmeny se spojovníky; kdo prostor zakládá, stane se jeho vlastníkem.
3. Sledujte, jak se prostor zakládá, a pak tlačítkem Open vstupte do jeho dashboardu.
4. Pozvěte členy do rolí, které potřebují.

Mapování na předpisy a normy

• ISO/IEC 27001 A.8.3 / A.5.15 — Omezení přístupu k informacím a řízení přístupu: pracovní prostor vymezuje, kdo se dostane k jeho procesům a datům, a přístup se uděluje pro každý prostor zvlášť.
• SOC 2 CC6.3 — Přístup podle rolí: členství a role se přidělují pro každý pracovní prostor a vynucují se na serveru.
• NIS2 čl. 21 odst. 2 písm. i) — Správa aktiv a řízení přístupu: každý pracovní prostor a jeho endpointy jsou v evidenci a mají vlastníka.

Přehled serveru a evidence endpointů

Stránky Server overview a Endpoint access v konzoli Bailey tvoří živý registr aktiv serveru: evidují každý pracovní prostor, každou cestu a každý chráněný endpoint, u endpointu i s jeho vlastníkem a pracovním prostorem, do kterého patří.

Server overview dává provozovateli přehled o situaci: počet pracovních prostorů, počet důvěryhodných zařízení a stav služeb samotné platformy. Endpoint access vypisuje každý chráněný hostname, před kterým stojí brána důvěryhodných zařízení, včetně dashboardů pracovních prostorů, gitops a frontendů automatizací, vždy s vlastníkem a pracovním prostorem. Obě stránky vycházejí ze skutečného živého stavu, ne z odděleně vedeného seznamu.

Klíčová fakta

• Server overview ukazuje počet pracovních prostorů, počet důvěryhodných zařízení a stav platformních služeb Bailey.
• Endpoint access vypisuje každý chráněný hostname za branou: dashboardy pracovních prostorů, gitops a frontendy automatizací.
• U každého endpointu je výslovně uvedený vlastník a pracovní prostor, do kterého patří.
• Evidence vzniká z živého stavu, takže na otázku auditu „co je vystavené a kdo to vlastní?“ odpovídá přímo.

Jak se používá

1. Otevřete Server overview, kde najdete stav platformy a počty.
2. Otevřete Endpoint access, kde uvidíte každou chráněnou cestu.
3. Ověřte, že každý endpoint má správného vlastníka a pracovní prostor.

Proč na tom záleží: Když se auditor zeptá, co je vystavené a kdo to vlastní, odpovědí je v Bailey jediná stránka, ne odpoledne strávené sháněním informací.

Mapování na předpisy a normy

• ISO/IEC 27001 A.5.9 — Soupis informací a dalších souvisejících aktiv: každý pracovní prostor a chráněný endpoint je vypsaný ze skutečného živého stavu.
• NIS2 čl. 21 odst. 2 písm. i) — Správa aktiv: vystavené služby jsou v evidenci i s vlastníky.
• SOC 2 CC6.1 — Zabezpečení logického přístupu: každý endpoint stojí za branou a má výslovně určeného vlastníka.

Správa zařízení a postup při ztrátě zařízení

Stránka Your devices v Bailey vypisuje každý prohlížeč spojený s identitou uživatele jako pojmenované důvěryhodné zařízení, které uživatel vidí, může ho označit a odebrat. Odebrání zařízení mu okamžitě odebere přístup v celé platformě, a proto je to správná reakce na ztrátu nebo krádež zařízení.

Každé zařízení nese štítek Root device (zařízení, které převzalo server), Admin-approved (schválené administrátorem) nebo Linked (propojené) a stránka vyznačuje, které zařízení se právě používá. Na stejné stránce uživatel propojí nové zařízení zadáním šestimístného kódu, který nový prohlížeč zobrazuje.

Bailey váže přístup na zařízení, nejen na heslo. Zloděj s odemčeným notebookem proto už platnou relaci má a samotná změna hesla ho nevyřadí. Vyřadí ho až odebrání zařízení: tím se zneplatní cookie zařízení v celé platformě, takže mu konzole i všechny aplikace v pracovních prostorech okamžitě přestanou důvěřovat. Bailey pojmenuje nové zařízení podle prohlížeče, takže několik prohlížečů na jednom počítači vypadá stejně, dokud je uživatel nepřejmenuje. Díky pojmenování všech zařízení provozovatel i ve stresu odebere to správné.

Klíčová fakta

• Štítky zařízení v Bailey jsou Root device, Admin-approved a Linked; aktuální zařízení je vyznačené.
• Nový prohlížeč se přidá zadáním jeho šestimístného kódu v Link a device.
• Zařízení se přejmenovávají ikonou tužky vedle názvu; výchozí označení přebírá Bailey z prohlížeče.
• Odebrání zařízení zneplatní jeho cookie v konzoli i ve všech aplikacích v pracovních prostorech najednou.
• Změna hesla relaci ukradeného zařízení neukončí; ukončí ji odebrání zařízení.

Jak se používá

1. V konzoli otevřete Your devices.
2. Projděte důvěryhodná zařízení a jejich štítky.
3. Každé zařízení pojmenujte ikonou tužky, aby se daly rozlišit prohlížeče na jednom počítači.
4. Nový prohlížeč přidáte zadáním jeho kódu v Link a device.
5. Při ztrátě nebo krádeži zařízení ho odeberte tady; přístup se mu okamžitě odebere všude. Správnou reakcí je právě tohle, ne změna hesla.

Proč na tom záleží: Přístup vázaný na zařízení znamená, že ukradený odemčený notebook je živá relace, kterou změna hesla nezastaví. Jedno kliknutí v seznamu zařízení ji zruší všude a pojmenovaná zařízení dovolí provozovateli bez váhání najít to správné.

Mapování na předpisy a normy

• SOC 2 CC6.2 / CC6.3 — Přidělování a odebírání přístupu: zařízení se schvalují i odebírají centrálně a okamžitě.
• ISO/IEC 27001 A.5.15 / A.8.1 — Řízení přístupu a koncová zařízení uživatelů: důvěryhodná zařízení jsou registrovaná, označená a lze je odebrat.
• NIS2 čl. 21 odst. 2 písm. j) — Zabezpečený přístup: důvěra vázaná na hardware se registruje a spravuje pro každou osobu zvlášť.

Osobní kopie a experimenty

Osobní kopie je v Bailey izolovaná větev pracovního prostoru (workspace). Dostane ji automaticky každý uživatel a ve výchozím stavu pracuje právě v ní. Nic, co v ní udělá, se hlavní větve (main) nedotkne, dokud sám nestiskne Deploy. Experiment je dočasná větev odvozená z vlastní kopie uživatele a omezená na jediný firemní proces. Slouží k vyzkoušení nápadu, který pak uživatel sloučí, převezme, nebo zahodí.

Každý uživatel má právě jednu osobní kopii. Bailey ji vytvoří a vybere, když uživatel poprvé otevře přehled pracovního prostoru. Není třeba pojmenovávat větev ani zakládat kopii a horní lišta záměrně nemá pro kopie žádný ovládací prvek: žádný rozbalovací seznam, štítek ani název kopie. Lišta ukazuje firemní proces a za ním záložky Description → Coding Agent ↻ Requirements → Deploy, které všechny pracují uvnitř kopie uživatele. V kopii může uživatel upravovat, sestavovat a prohlížet výsledek, aniž by zasáhl do práce kohokoli jiného nebo do živé hlavní větve.

Vše ostatní kolem kopií je schované v jediné nabídce Advanced úplně vpravo. Položka See a colleague's version vypíše kopie všech ostatních uživatelů a po rozbalení kterékoli z nich se ukážou experimenty daného kolegy na aktuálním firemním procesu. Když ji uživatel otevře, objeví se jantarový pruh „You are in ⟨name⟩'s copy — your edits save to their copy“ (případně s názvem kolegova experimentu) a tlačítko Switch back to my copy pro návrat do vlastní kopie. Kopie kolegů nejsou zamčené: uživatel v nich může upravovat úplně stejně jako ve své a pruh je tu proto, aby vždy věděl, čí kopii právě mění.

Experiment se pojmenuje podle toho, co se zkouší (například „Ověřit DIČ dodavatelů v ARES“), nikdy názvem větve. Bailey zapíše aktuální stav daného firemního procesu v kopii do commitu, přesně z tohoto stavu vytvoří větev a otevře experiment pod zeleným pruhem „You are in an experiment on ⟨business process⟩: ⟨title⟩“. Pruh nabízí čtyři cesty ven:

• Back to my copy vrátí uživatele do jeho kopie a experiment nechá běžet v nabídce Advanced, odkud se do něj dá kdykoli vrátit. Experiment tím nekončí.
• Merge back into my copy převede práci do kopie posunem vpřed (fast-forward), obnoví live-dev nasazení kopie, experiment zruší a vrátí uživatele do kopie. Pokud se kopie mezitím posunula natolik, že vznikne konflikt, sloučení nic neodhaduje a rebase předá programovacímu agentovi, který ho provede uvnitř experimentu.
• Discard experiment větev skutečně smaže i s jejími soubory a live-dev kontejnery. Předchází tomu potvrzovací dialog, který vyjmenuje nesloučenou práci, o kterou se tím přijde.
• Use this version without merging udělá z experimentu novou podobu kopie, bez slučování a bez řešení konfliktů. Cokoli kopie pro daný firemní proces obsahovala, včetně nezapsaných úprav, se nejdřív odloží jako nový experiment s názvem „My previous ⟨process⟩ work — ⟨date and time⟩“. Pokud nebylo co uložit, žádný experiment nevznikne a uživatel se to dozví. Zdrojový experiment se pak uzavře. Výsledek vždy leží nad hlavní větví. Pokud experiment hlavní větev už obsahoval, kopie se na něj posune vpřed a zachová jeho vlastní commity. Pokud se obě větve rozešly, přenese obsah experimentu nad hlavní větev jediný obnovovací commit. Příští Deploy je tak prostý fast-forward bez kroku Sync.

Kopie pokrývá celý pracovní prostor, experiment jen jeden firemní proces, protože každý firemní proces je samostatný git repozitář. Experiment přes několik procesů by ve skutečnosti byl několik nesouvisejících větví. Bailey proto v nabídce Advanced ukazuje jen experimenty aktuálního procesu (když žádné nejsou, zobrazí „No experiments on ⟨process⟩“), server odmítne do experimentu zahrnout jakýkoli jiný proces a když uživatel uvnitř experimentu přepne na jiný proces, vrátí se do své vlastní kopie a Bailey mu to oznámí.

Experiment se do hlavní větve nikdy nedostane. Uvnitř experimentu se záložka Deploy vůbec nevykreslí a server publikování z experimentu odmítne, i kdyby o ně někdo požádal. Práce opouští experiment jedině sloučením do kopie, ze které vznikl, a kopii opouští jedině vědomým stisknutím Deploy. Je to jediná cesta, vede jedním směrem a u každého jejího kroku je jméno konkrétního člověka.

Klíčová fakta

• Každý uživatel Bailey má v každém pracovním prostoru právě jednu osobní kopii, která se vytvoří a vybere automaticky při první návštěvě.
• Horní lišta nemá výběr kopie; ke kopiím a experimentům kolegů se uživatel dostane přes Advanced → See a colleague's version.
• Úpravy v kopii kolegy jsou povolené a upozorňuje na ně jantarový pruh; experimenty označuje zelený pruh.
• Experiment patří právě k jednomu firemnímu procesu, protože každý firemní proces je samostatný git repozitář.
• Z experimentu vedou čtyři cesty: Back to my copy (experiment běží dál), Merge back into my copy, Use this version without merging a Discard experiment.
• Konflikty při slučování se neřeší automaticky; rebase uvnitř experimentu dostane na starost programovací agent.
• Use this version without merging odloží předchozí práci v kopii jako experiment s datem, takže se nic neztratí.
• Zrušení experimentu smaže jeho větev, soubory a live-dev kontejnery, a to až po dialogu, který vypíše nesloučenou práci.
• V experimentu se záložka Deploy nevykresluje a server z něj publikování odmítá.
• Do hlavní větve vede jediná cesta: experiment → osobní kopie → Deploy.

Jak se používá

1. Stiskněte u pracovního prostoru Open a otevře se jeho přehled; vaše vlastní kopie už je aktivní.
2. Kopii někoho jiného si prohlédnete přes Advanced → See a colleague's version, po jejím rozbalení otevřete některý z kolegových experimentů; až budete hotovi, stiskněte Switch back to my copy.
3. Vyberte firemní proces, otevřete Advanced → Start a new experiment a pojmenujte, co zkoušíte; zelený pruh uvádí název procesu.
4. V experimentu pracujete stejně jako v kopii: stejné záložky, stejné live-dev, jen na vlastní větvi tohoto jednoho procesu.
5. Přepnutím na jiný firemní proces experiment opustíte a vrátíte se do své kopie.
6. Stiskem Merge back into my copy převedete práci do kopie; experiment se automaticky zruší.
7. Nebo stiskněte Use this version without merging a kopie převezme podobu experimentu; předchozí práce se odloží jako experiment s datem a zdrojový experiment se uzavře.
8. Tlačítkem Back to my copy můžete experiment kdykoli opustit a nechat ho běžet v Advanced → Experiments on ⟨process⟩.
9. Nebo ho tlačítkem Discard experiment úplně smažte.
10. Všechno, co postavíte, zůstává v kopii, dokud nestisknete Deploy.

Proč na tom záleží: Izolované kopie oddělují prostředí už ve výchozím nastavení a experimenty zlevňují zkoušení nápadů. Z kopie odbočíte, nápad ověříte a pak ho sloučíte, nebo zahodíte, a sdílená hlavní větev přitom není v ohrožení ani na okamžik. Každý krok je výslovný a dá se přiřadit konkrétnímu člověku. Do hlavní větve vede jediná cesta, vědomý Deploy z vlastní kopie uživatele.

Mapování na předpisy a normy

• ISO/IEC 27001 A.8.31 — Oddělení vývojového, testovacího a produkčního prostředí: osobní kopie i každý experiment z ní odvozený a omezený na jeden firemní proces oddělují rozpracovanou práci od hlavní větve i od všech nasazených prostředí; experiment do hlavní větve nemá vůbec žádnou cestu.
• ISO/IEC 27001 A.8.32 — Řízení změn: změna putuje pevně danou a zaznamenanou cestou (experiment → osobní kopie → main) a každý krok je výslovná akce konkrétního člověka, nic se nestane jen mimochodem.
• SOC 2 CC8.1 — Řízení změn: změny vznikají v izolované kopii a do hlavní větve se dostanou jen vědomým stisknutím Deploy; nic se nesloučí samo.
• NIS2 čl. 21 odst. 2 písm. e) — Bezpečnost při vývoji: zkoušení probíhá na jednorázové větvi vlastní kopie vývojáře, takže neprověřená práce se nikdy nestane sdíleným základem.

Firemní procesy

Firemní proces je v Bailey jednotka, kterou se staví, nasazuje a provozuje. Při jeho založení vzniknou kostry jeho automatizací, backendu a frontendu, a proces pak tvoří hranici pro svůj popis, kód, kontroly CVE, prostředí, tajemství, zálohy i firewall.

Firemní proces se zakládá v okně New business process a jeho název se píše malými písmeny se spojovníky. Frontend, který přitom vznikne, je rovnou produkční webová aplikace procesu, nejde o žádnou maketu. Jakmile běží, přidělí mu Bailey skutečný směrovatelný hostname s hotovým TLS na vlastní doméně serveru Bailey, takže není potřeba zakládat zvláštní hostingový účet, DNS zónu ani certifikát. Vlastní doménu lze přidat později, nutná ale není nikdy. Pokud chce organizace aplikaci hostovat jinde, může administrátor zrcadlit pracovní prostor do vlastního git remote organizace, takže zdrojový kód nezůstane uzamčený u dodavatele. Backend zůstává úplně mimo veřejný internet a dostane se k němu jen frontend přes privátní síť pracovního prostoru.

Klíčová fakta

• Každý nový firemní proces v Bailey vznikne se dvěma automatizacemi: backendem a frontendem.
• Názvy firemních procesů se píšou malými písmeny se spojovníky.
• Frontend je produkční webová aplikace a jakmile běží, dostane na doméně serveru Bailey směrovatelný hostname zabezpečený TLS.
• Vlastní doména je volitelná.
• Backend není vystavený do veřejného internetu; dostane se k němu jen frontend přes privátní síť pracovního prostoru.
• Administrátor může pracovní prostor zrcadlit do externího git remote, takže si zákazník zdrojový kód může odnést s sebou.
• Popis, kód, kontroly CVE, prostředí, tajemství, zálohy i firewall se vedou pro každý firemní proces zvlášť.

Jak se používá

1. Otevřete přepínač firemních procesů vlevo nahoře.
2. Klikněte na New business process.
3. V okně zadejte název a stiskněte Create.
4. Bailey vytvoří kostru procesu a rovnou ho vybere.

Mapování na předpisy a normy

• ISO/IEC 27001 A.5.9 — Inventář informací a dalších souvisejících aktiv: každý firemní proces je pojmenovaná část systémů a má svého vlastníka.
• ISO/IEC 27001 A.8.25 — Bezpečný životní cyklus vývoje: práce je organizovaná po procesech a každý z nich má vlastní pipeline a opatření.

Popis procesu a vývojové diagramy

Záložka Description v Bailey obsahuje živou specifikaci každého firemního procesu, obvykle co proces dělá, pro koho a jaká pravidla musí dodržet. Popis se verzuje spolu s kódem procesu, takže dokumentace leží přímo vedle kódu a nežije odděleně v samostatné wiki.

Editor pracuje s formátovaným textem a podporuje zkratky Markdownu. Průběh procesu se kreslí, nepíše se jako kód diagramu. Tlačítko Insert flowchart na panelu nástrojů otevře editor vývojových diagramů, do kterého uživatel vkládá uzly typu Process, Decision nebo Terminal, spojuje je tažením z úchytu jednoho uzlu na druhý, popisuje je a tlačítkem Save diagram vloží hotový diagram do specifikace. Úpravy se ukládají samy, což ukazuje indikátor na obrazovce, a Ctrl+S uloží okamžitě. Uložení ale ještě neznamená novou verzi: verzí procesu se text stane až při příštím Deploy nebo Sync.

Klíčová fakta

• Každý firemní proces v Bailey má záložku Description s editorem formátovaného textu, který podporuje zkratky Markdownu.
• Editor vývojových diagramů nabízí tři typy uzlů: Process, Decision a Terminal.
• Save diagram vloží hotový vývojový diagram přímo do specifikace.
• Úpravy se ukládají automaticky; Ctrl+S vynutí okamžité uložení.
• Popis se stane verzí procesu až při příštím Deploy nebo Sync, ne v okamžiku uložení.
• Ze specifikace vychází programovací agent, když proces staví (viz tlačítko Build automation).

Jak se používá

1. Otevřete záložku Description.
2. Napište specifikaci jako formátovaný text.
3. Klikněte na panelu nástrojů na Insert flowchart a nakreslete průběh: přidejte uzly, spojte je tažením a stiskněte Save diagram.
4. Úpravy se ukládají samy a Ctrl+S uloží okamžitě; verzí se text stane při příštím Deploy nebo Sync.

Mapování na předpisy a normy

• ISO/IEC 27001 A.5.37 — Dokumentované provozní postupy: proces a jeho pravidla jsou sepsané a udržují se aktuální spolu s kódem.

Programovací agent a požadavky

Coding Agent je v Bailey AI programovací agent, který běží přímo v platformě. Automatizace firemního procesu staví podle jeho specifikace v izolované kopii uživatele a k produkčním datům nemá přístup. Doplňuje ho záložka Requirements & tests, kde jsou pravidla procesu uložená jako spustitelné kontroly a u každé se sleduje stav.

Záložka Coding Agent nabízí v pracovním prostoru chatovací panel a strom souborů. Agent pracuje v izolované kopii uživatele. Na internet se dostane, protože ho ke své práci potřebuje, k produkční databázi a uživatelským datům v ní ale ne, a jeho odchozí provoz omezuje seznam povolených cílů ve firewallu pracovního prostoru. Všechno, co vytvoří, musí před nasazením projít záložkou Deploy a kontrolami CVE.

Změny nemusejí jít přes agenta. Podzáložka Files v záložce Coding Agent je plnohodnotný editor nad pracovním stromem kopie; úpravy se ukládají samy a ⌘/Ctrl+S uloží okamžitě. Příkladem je nastavení memory_reservation_policy na hodnotu always-on v souboru automation.toml workeru na pozadí. Worker, kterého nebudí žádné příchozí požadavky, pak zůstane v paměti a při nečinnosti se neuspí. Jako každá změna v kopii se ani ruční úprava nedotkne hlavní větve dřív než při Deploy a verzí na větvi kopie se stane až při tomto Deploy nebo při Sync, ne v okamžiku uložení.

Každá automatizace v kopii má také live-dev nasazení, tedy běžící náhled, který se při změnách kódu sám znovu sestaví. Uživatel ho otevře odkazem frontendové automatizace v panelu Environment a proklikne si skutečnou aplikaci dřív, než se cokoli dostane do hlavní větve.

Požadavky se nepřepisují ručně. Tlačítko Build automation v záložce Description, hned vedle Save, předá specifikaci agentovi. Ten podle ní proces postaví, spustí live-dev náhled a navrhne požadavky, které ze specifikace vyčetl. Návrhy agenta dostávají identifikátory AI- a čekají, až je uživatel přijme, přeformuluje, nebo vyřadí. Požadavky, které napíše uživatel, dostávají identifikátory REQ-, takže ze seznamu je vždy vidět, která pravidla pocházejí od člověka. Tlačítko Write tests pošle agenta zpět, aby požadavky pokryl skutečnými testy.

Stav požadavku určuje frontu práce agenta. Požadavek, který napíše uživatel, začíná ve stavu pending (zapsaný, zatím netestovaný). Akce Requirements next předá agentovi první požadavek v pořadí stromu, který není ve stavu pass. Za práci k udělání se tedy počítají pending, fail i retest a z fronty požadavek vyřadí jedině pass. Stavy pass a fail uživatel nenastavuje: vzniknou z běhu testů, nebo z toho, co agent při stavbě zjistil a zaznamenal. Uživatel může přijmout návrh, čímž ho převede do závazného zadání a požadavek se začne testovat, nebo může procházející požadavek poslat zpět k nové kontrole. proposed je jediný stav, který znamená „zatím není součástí závazného zadání“, a běhy testů navržené požadavky přeskakují. Stav a pokrytí testy se sledují odděleně: záložka hledá test, který nese identifikátor požadavku, takže požadavek může ukazovat pass jen na základě úsudku agenta nebo uživatele, aniž by za ním stál jakýkoli test.

Klíčová fakta

• Coding Agent v Bailey běží uvnitř platformy, v izolované kopii uživatele, nikoli vedle ní.
• Agent má přístup k internetu, k produkční databázi ani k produkčním uživatelským datům se ale nedostane.
• Odchozí provoz agenta omezuje seznam povolených cílů ve firewallu pracovního prostoru.
• Výstup agenta musí před nasazením projít záložkou Deploy a skenováním CVE.
• Podzáložka Files je plnohodnotný ruční editor nad kopií; ⌘/Ctrl+S uloží okamžitě.
• Každá automatizace v kopii má live-dev nasazení, které se při změnách kódu znovu sestaví.
• Identifikátory požadavků: AI- pro návrhy agenta, REQ- pro požadavky napsané člověkem.
• Stavy požadavků: proposed, pending, fail, retest a pass; z fronty práce odchází jen pass a požadavky ve stavu proposed se netestují.
• Uživatel nemůže pass ani fail nastavit přímo; může přijmout návrh nebo poslat procházející požadavek zpět k nové kontrole.
• Pokrytí testy se sleduje odděleně od stavu: požadavek může ukazovat pass i bez testu.

Jak se používá

1. Otevřete záložku Coding Agent a spusťte relaci nad kopií.
2. Nebo stiskněte Build automation v záložce Description: agent proces postaví podle specifikace, naběhne live-dev náhled a agent navrhne testovatelné požadavky.
3. Když je potřeba, upravte soubory ručně v podzáložce Files; změny se ukládají samy a zůstávají v kopii.
4. Klikněte na frontend běžící automatizace, otevřete ho a proklikejte si ho.
5. Otevřete Requirements & tests, přijměte nebo přeformulujte návrhy agenta s identifikátorem AI-, doplňte vlastní požadavky REQ-, stiskněte Write tests, aby je pokryly testy, a pak stiskněte Deploy.

Proč na tom záleží: U programovacího agenta v Bailey rozhoduje hlavně to, kde běží. Pracuje v izolované kopii, za firewallem pracovního prostoru a mimo dosah produkčních dat, takže jeho výstup se kontroluje, skenuje a vědomě nasazuje jako každá jiná změna. Na otázku „dělá to pořád, co jsme slíbili?“ pak v záložce Requirements & tests stačí stisknout tlačítko a není kvůli ní potřeba svolávat poradu.

Mapování na předpisy a normy

• ISO/IEC 27001 A.8.25 / A.8.31 — Bezpečný životní cyklus vývoje a oddělení prostředí: agent staví v izolované kopii a sandboxu a produkce se nikdy přímo nedotkne.
• NIS2 čl. 21 odst. 2 písm. e) — Bezpečnost při vývoji: výstup agenta před nasazením projde skenováním CVE a kontrolou.
• SOC 2 CC6.6 — Ochrana hranic systému: odchozí provoz agenta omezuje seznam povolených cílů ve firewallu pracovního prostoru.
• DORA čl. 24–26 — Testování odolnosti: požadavky jsou spustitelné specifikace, které lze kdykoli spustit znovu.

Vývojové, testovací a produkční prostředí

Bailey vede každý firemní proces třemi prostředími, Development (vývojové), Staging (testovací) a Production (produkční), a každé z nich má vlastní databázi, vlastní úložiště souborů a vlastní izolovanou síť Dockeru. Data jednoho prostředí nikdy nejsou daty jiného a prostředí se k sobě po síti nedostanou.

Protože má každé prostředí oddělená data i síť, záznamy, přílohy a účetní zápisy z jednoho prostředí se v jiném nikdy neobjeví a uživatelská ani produkční data se mezi prostředími nesdílejí. Aplikaci lze spustit ve vývojovém prostředí a v testovacím ji pořádně prohnat chybnými součty, špatně zapsanými DIČ a záměrnými hraničními případy, aniž by se kdokoli dotkl skutečných produkčních dat, protože ta v těchto prostředích vůbec nejsou.

Rozdělení na prostředí zároveň odděluje povinnosti. Produkce má vlastní bránu, takže zkušený člen týmu může kód prověřit a zkontrolovat dřív, než se do produkce dostane. Člen týmu (member) staví a nasazuje přes vývojové a testovací prostředí a povýšení do produkce je vědomý krok, který lze přezkoumat. Ve vývojovém prostředí běží to, co je v hlavní větvi. Nic se tam nedostane, dokud uživatel nestiskne Deploy, který publikuje jeho kopii do hlavní větve a nasadí ji do Development.

Klíčová fakta

• Bailey má pro každý firemní proces tři prostředí: Development, Staging a Production.
• Každé prostředí má vlastní databázi, úložiště souborů a izolovanou síť Dockeru a prostředí se k sobě navzájem nedostanou.
• Produkční data se ve vývojovém ani testovacím prostředí nikdy nevyskytují.
• Ve vývojovém prostředí běží obsah hlavní větve; Deploy publikuje kopii uživatele do hlavní větve a nasadí ji do Development.
• Povýšení z Development do Staging a ze Staging do Production je samostatný, výslovný krok.
• Povýšení do Production má podle návrhu přijít až po schválení zkušeným revizorem, čímž se oddělují povinnosti.
• Pipeline je vidět na stránce Deployments.

Jak se používá

1. Otevřete Deployments a projděte si pipeline: Development, Staging, Production.
2. Stavte a testujte v osobní kopii; stiskem Deploy ji publikujete do hlavní větve a nasadíte do Development.
3. Jakmile změna běží ve vývojovém prostředí, povyšte ji do Staging a vyzkoušejte aplikaci na vlastních datech testovacího prostředí.
4. Před vědomým povýšením do Production nechte změnu schválit zkušeným revizorem.

Proč na tom záleží: Tři prostředí, tři databáze, tři úložiště souborů a tři izolované sítě Dockeru znamenají, že testování ve vývojovém a testovacím prostředí nemůže skutečná produkční data nikdy vyzradit ani poškodit a změny do produkce procházejí povýšením, které lze přezkoumat. Oddělení povinností i izolace prostředí vyplývají přímo z modelu prostředí a nikdo je nemusí dodělávat později.

Mapování na předpisy a normy

• ISO/IEC 27001 A.8.31 — Oddělení vývojového, testovacího a produkčního prostředí: vývojové, testovací i produkční prostředí běží každé na vlastní databázi, úložišti souborů a síti Dockeru, navzájem se k sobě nedostanou a produkční data se v testovacím prostředí nikdy nevyskytují.
• SOC 2 CC8.1 — Řízení změn: změny se staví a testují v nižších prostředích a do produkce se dostanou jen vědomým povýšením, které lze přezkoumat.
• GDPR čl. 5 odst. 1 písm. c) — Minimalizace údajů: skutečné osobní údaje jsou jen v produkci a vývojové i testovací prostředí se testuje bez produkčních uživatelských dat.

Deploy a Sync: jak se změna dostane do hlavní větve

Deploy je v Bailey jediná akce, která publikuje jeden firemní proces do chráněné hlavní větve (main) a nasadí ho do vývojového prostředí. Sync je samostatný krok, který do tohoto firemního procesu nejdřív přenese práci, kterou už kolega do hlavní větve publikoval. Je to jediné místo v Bailey, kde se řeší rozdíly oproti hlavní větvi.

Jedno tlačítko Deploy provede pro vybraný firemní proces celý sled: zapíše rozpracovanou práci do commitu, posune na ni hlavní větev (fast-forward) a nasadí ji do vývojového prostředí. Přitom sleduje právě to jedno nasazení, které spustilo, a druhé nezakládá. Během běhu je na tlačítku Working… a pod hlavičkou se otevře posuvný Build log. Log průběžně ukazuje každý řádek nasazení: sestavení image každého kontejneru, krok build.sh, který kompiluje produkční balík (vite build nebo go build), a značky Prepared jednotlivých procesů. Kolem tlačítka Deploy jsou tři záložky ke kontrole: Diff (přesně to, co se stane hlavní větví), History (commity kopie i hlavní větve se značkami nasazení) a Supply Chain Security (přesný seznam CVE v image, kterou by toto nasazení sestavilo).

Deploy je fast-forward-only ve dvou smyslech. Hlavní větev vždy jen posouvá vpřed a vždy publikuje jen vybraný firemní proces, protože každý firemní proces je samostatný git repozitář; nasazení jednoho procesu proto nemůže s sebou přibalit napůl hotovou změnu v jiném. Pokud mezitím kolega do hlavní větve něco publikoval, je kopie pozadu a Bailey nasazení odmítne. Místo neaktivního tlačítka se objeví věta „Main has changes you don't have yet — sync first.“ a tlačítko Go to Sync. Krok Sync se zobrazuje jako první záložka, ještě před Description, a to jen tehdy, když hlavní větev daného procesu obsahuje commity, které kopie nemá, a jen ve vlastní kopii uživatele. Jakmile kopie hlavní větev dožene, zmizí. Každý příchozí commit uvádí s předmětem a autorem a jeho jediné tlačítko, Pull main into ⟨process⟩, přehraje práci uživatele nad hlavní větví a obnoví live-dev náhled, pokud se změnila image. Skutečný konflikt předá programovacímu agentovi, který ho dořeší ručně. Sync se týká vždy jednoho firemního procesu: proces, který je srovnaný, krok Sync neukazuje, i kdyby jiný proces ve stejné kopii zaostával o mnoho commitů. Krok Sync i hláška „sync first“ u Deploy vycházejí z téhož měření, takže si nemohou odporovat.

Nasazení této verze s přepsáním hlavní větve

Vedle Go to Sync nabízí Bailey záměrně nenápadnou alternativu, Deploy this version, overwriting main…. Její dialog načte aktuální stav hlavní větve a vypíše každý commit, který kopie nemá, se zprávou, autorem a krátkým identifikátorem. Pokud se seznam načíst nepodaří, tlačítko zůstane neaktivní a dialog vysvětlí proč. Potvrzení vyžaduje napsat název firemního procesu, což je stejná pojistka jako při obnově produkčních dat. Výsledek je pevně daný: hlavní větev bude obsahovat přesně to, co kopie, a přijde i o vše, co do ní přibylo a co kopie nemá; žádný režim ani pravidlo sloučení se nevybírá. Historie zůstává zachovaná. Commity uživatele se přehrají na špičku hlavní větve jeden po druhém a nic se nezplošťuje, a kde by zůstaly soubory, které má navíc hlavní větev, srovná jeden další commit strom do identické podoby a viditelně je odstraní. Vlastní commity hlavní větve zůstávají pod tím a jsou dál dosažitelné; nic se nepřepisuje ani se nepoužívá force-push. Před publikováním Bailey ověří, že publikovaný strom je bajt po bajtu shodný s kopií, a jinak nepublikuje nic. Konflikt, který žádné pravidlo nerozhodne (jedna strana smazala soubor, který druhá upravila), nic nezmění a putuje k programovacímu agentovi stejně jako u zablokovaného Sync.

Tlačítka Edit this version a Revert dev to this version

Dialog Inspect u každého nasazení obsahuje Edit this version. To promění kopii daného firemního procesu u uživatele přesně v tuto nasazenou verzi pomocí obnovovacího commitu nad hlavní větví, takže kopie je o jeden commit napřed a o žádný pozadu a dá se opravit a nasadit bez synchronizace. Cokoli kopie obsahovala předtím, se odloží jako experiment s datem. Přijímají se jen verze, které tento pracovní prostor pro daný firemní proces skutečně nasadil, nikoli libovolný identifikátor commitu. Ve vývojovém prostředí nabízí Inspect také Revert dev to this version (na rozdíl od tlačítka Roll back u řádků historie, které vrátí jedno prostředí zpět bez zásahu do hlavní větve). Protože se vývojové prostředí nasazuje z hlavní větve, je návrat vývojového prostředí jeden nový commit v hlavní větvi připsaný uživateli; chybná verze zůstane v historii. Dialog upozorní, že všechny ostatní kopie budou v tomto procesu o jeden commit pozadu a že jejich příští Sync návrat přinese a jejich nepublikovanou práci přehraje nad ním. Testovací a produkční prostředí takové tlačítko nemají, zpět se v nich jde přes povýšení a rollback.

Označení CVE jako mimo rozsah

Nález, který se netýká (nedosažitelná cesta v kódu, falešně pozitivní výsledek, riziko ošetřené jinde), lze v záložce Supply Chain Security označit jako mimo rozsah. Rozhodnutí se zapíše do zdrojového stromu firemního procesu v souboru cve-waivers.yaml, verzovaného v gitu, i s tím, kdo ho učinil, kdy a proč, a do hlavní větve se dostane s příštím Deploy. Každé CVE mimo rozsah je uvedené ve zvláštní části auditního logu. V této záložce ho revizor může vrátit do rozsahu a v záložce Supply chain produkčního prostředí ho auditoři vidí jen pro čtení.

Klíčová fakta

• Deploy jednou akcí zapíše rozpracovanou práci do commitu, posune hlavní větev vpřed (fast-forward) a nasadí do vývojového prostředí.
• Hlavní větev je chráněná a dá se jen posouvat vpřed; Deploy nikdy neslučuje ani nepoužívá force-push.
• Každý firemní proces je samostatný git repozitář, takže Deploy i Sync se vždy týkají jednoho procesu.
• Když je kopie za hlavní větví, nahradí Deploy hláška „Main has changes you don't have yet — sync first.“ a tlačítko Go to Sync.
• Záložka Sync se objevuje, jen dokud má hlavní větev commity, které kopie nemá, vypisuje je s předmětem a autorem a nabízí Pull main into ⟨process⟩.
• Deploy this version, overwriting main… vyžaduje napsat název firemního procesu, vypíše každý nahrazený commit a publikuje, jen když je výsledek bajt po bajtu shodný s kopií.
• Edit this version přijímá jen verze, které pracovní prostor pro daný firemní proces skutečně nasadil.
• Revert dev to this version existuje jen ve vývojovém prostředí; testovací a produkční prostředí používají povýšení a rollback.
• Výjimky z CVE jsou v souboru cve-waivers.yaml ve zdrojovém stromu, i s tím, kdo, kdy a proč.
• Build log průběžně ukazuje sestavení image, krok build.sh a značky Prepared jednotlivých procesů.

Jak se používá

1. Otevřete Deploy.
2. Pokud je vidět záložka Sync nebo Deploy hlásí „sync first“, otevřete Sync, projděte příchozí commity a stiskněte Pull main into ⟨process⟩; jakmile kopie hlavní větev dožene, záložka zmizí.
3. Zkontrolujte Diff, History a záložku Supply Chain Security.
4. CVE, které se vás netýká, označte jako mimo rozsah; zapíše se do zdrojového stromu i s tím, kdo, kdy a proč.
5. Stiskněte Deploy; kopie se posune do hlavní větve a vývojové prostředí přejde do stavu Healthy.
6. Pokud je správná verze ta v kopii a synchronizovat nechcete, použijte Deploy this version, overwriting main…, přečtěte si, čí commity nahrazuje, a potvrďte to napsáním názvu procesu.
7. Chcete-li vyjít z běžící verze, otevřete v Deployments její Inspect a stiskněte Edit this version; ve vývojovém prostředí vrátí Revert dev to this version sdílené vývojové prostředí zpět pro všechny.
8. Až budete připraveni, verzi povyšte.

Proč na tom záleží: Kontrola zranitelností běží nad image, která skutečně poběží, a nespoléhá na nějaký starší sken. Protože publikování jen posouvá hlavní větev vpřed, nikdo nemůže nasadit přes změnu kolegy: jeho práce se nejdřív vědomě převezme a nová změna se položí nad ni. Bezpečnostní kontrola i integrace jsou kroky samotného postupu a nestojí jako samostatné brány mimo něj.

Mapování na předpisy a normy

• ISO/IEC 27001 A.8.8 — Řízení technických zranitelností: image se před nasazením skenuje na CVE a každý nález odkazuje na své bezpečnostní upozornění.
• NIS2 čl. 21 odst. 2 písm. e) — Bezpečnost při pořizování, vývoji a údržbě včetně řešení zranitelností: výjimky se verzují přímo ve zdrojovém stromu a dají se přezkoumat.
• DORA čl. 8–9 — Identifikace rizik ICT a ochrana: díky skenování před nasazením je identifikace rizik automatická a auditovatelná.
• SOC 2 CC8.1 — Řízení změn: commit, publikování a nasazení tvoří jednu řízenou a sledovatelnou operaci, kterou Bailey rovnou odmítne, pokud kopie není přímým pokračováním hlavní větve (fast-forward).
• ISO/IEC 27001 A.8.32 — Řízení změn: integrace (Sync) je výslovný krok s uvedeným autorem, oddělený od vydání (Deploy), a obojí se týká vždy jednoho firemního procesu.

Postupné nasazení a blue-green povýšení

Při postupném nasazení v Bailey se změna posouvá vždy o jedno prostředí dál, z vývojového do testovacího a z testovacího do produkčního, a každý krok je přepnutí typu blue-green. Bailey provozuje tři sloty aplikace nad dvěma trvalými databázemi, takže živý slot během povýšení dál obsluhuje uživatele a záložní slot je vždy jen jedno přepnutí daleko.

Při povýšení prostředí se nečinný slot spustí nad živou databází daného prostředí, ingress se přesměruje na něj a starý slot se ukončí. Pipeline průběžně ukazuje aktuální krok, zatímco se záložní slot sestavuje a startuje, a uživatelé nezaznamenají žádný výpadek. Povýšení přenáší image beze změny: Bailey znovu nasadí přesně ty bajty, které byly sestaveny a zkontrolovány, i když se zdrojový kód v pracovním prostoru mezitím změnil. V produkci tak běží přesně to, co prošlo testovacím prostředím, a ne nově sestavená verze.

Pipeline ukazuje, který slot je živý, který záložní, co je ve stavu Healthy a jakou verzi které prostředí provozuje. Každé prostředí nese dvě samostatné značky. Zeleně vyplněný kruh znamená, že je do prostředí něco nasazené. Odznak v rohu ukazuje, co dělají kontejnery: zelená fajfka jen tehdy, když byl každý kontejner zaznamenán v běhu, fialové ↻, když se některý opakovaně restartuje, červené varování, když některý vůbec neběží, modrá tečka, když prostředí spí a při přístupu se probudí, a šedá tečka, když Bailey kontejnery tohoto prostředí nenačetl. Prostředí může být vyplněné zeleně, a přitom bez fajfky, což znamená, že kód je nasazený, ale není v pořádku; fajfku nikdy nedostane prostředí, které nebylo zkontrolováno. Akce spuštěná uživatelem (restart, zastavení, probuzení) dostane třetí značku, otočný indikátor v protějším rohu, který tam zůstane, dokud Bailey akci neuvidí dokončenou. Akce uživatele a stav kontejnerů se tak nikdy navzájem nepřepíšou.

Klíčová fakta

• Prostředí jsou vývojové, testovací a produkční a povyšuje se vždy o jeden krok.
• Každé povýšení je přepnutí blue-green: nečinný slot startuje nad živou databází, ingress se přesměruje a starý slot se ukončí.
• Bailey používá tři sloty aplikace nad dvěma trvalými databázemi.
• Povýšení znovu nasadí přesně ty bajty image, které prošly kontrolou; nikdy nejde o nové sestavení.
• Z vývojového do testovacího prostředí může povyšovat kterýkoli člen týmu; produkce vyžaduje nejdřív zmrazení a audit.
• Odznaky prostředí: zelená fajfka (vše běží), fialové ↻ (restartuje se), červené varování (neběží), modrá tečka (spí, probudí se při přístupu), šedá tečka (nenačteno).
• Otočný indikátor v protějším rohu označuje akci spuštěnou uživatelem, dokud Bailey nevidí, že je dokončená.
• Testovací prostředí používá vlastní data, nikdy produkční.

Jak se používá

1. Otevřete Deployments.
2. Stiskněte Promote all to Staging a sledujte, jak přepnutí blue-green doběhne do stavu Healthy.
3. Vyzkoušejte aplikaci v testovacím prostředí, které běží na vlastních datech.
4. Testovací prostředí zmrazte (Freeze), nechte provést audit a pak stiskněte Promote to Production.

Proč na tom záleží: Každé povýšení je přepnutí blue-green bez výpadku, které nasazuje přesně zkontrolovanou image. Povyšovat se proto dá i během pracovního dne a návrat na záložní slot je stejně rychlý.

Mapování na předpisy a normy

• ISO/IEC 27001 A.8.31 — Oddělení vývojového, testovacího a produkčního prostředí: změna se nasazuje přes izolovaná prostředí, z nichž každé má vlastní databázi a síť.
• SOC 2 CC8.1 — Řízení změn: do produkce se změny dostanou jen vědomým a sledovatelným povýšením zkontrolované image.
• DORA čl. 9 — Ochrana a prevence: přepnutí bez výpadku minimalizuje dopad změn na dostupnost kritických funkcí.

Zmrazení a audit: princip čtyř očí před ostrým provozem

Zmrazení a audit (Freeze a Audits) je brána v Bailey, kterou musí projít každá změna, než se dostane do ostrého provozu. Auditor nebo admin zmrazí testovací prostředí, a tím uzamkne přesně ten image, který se prověřuje. Audit pak dělá v kopii přesně této verze a nakonec podepíše písemnou zprávu, nebo navrhne opravu. Každé zmrazení, změna auditních pravidel i verdikt se zapisují i se zprávou do bitswan.yaml.

Rovnou do ostrého provozu nepovyšuje nikdo. Zmrazení testovacího prostředí připíchne prověřovaný image na pevný tag a zavře povyšování z vývojového prostředí do testovacího, takže se auditovaná verze během kontroly nemůže změnit. Běžný člen (member) tlačítko pro povýšení do produkce nikdy nemá aktivní a práci předává auditorovi, jak to vyžaduje oddělení povinností. Auditní pravidla (audit policy) určují, kolik podpisů auditorů zmrazený image potřebuje, vždy alespoň jeden. Promote to Production se odemkne teprve ve chvíli, kdy jsou pravidla splněná, a jediné Request changes bránu zablokuje. Jakmile auditovaný image dorazí do ostrého provozu, testovací prostředí se samo rozmrazí.

Když auditor otevře audit, dostane zdrojový kód, ze kterého byl zmrazený image sestaven. Pracuje s ním v běžné kopii se stejným programovacím agentem, prohlížečem souborů i zobrazením rozdílů, jaké používá při každodenní práci. Auditní zpráva je soubor uložený vedle zdrojového kódu, ale mimo něj, takže návrh opravy obsahuje jen kód. Nic, co se v kopii udělá, zmrazený image nezmění, protože podpis se váže k otisku (hash) obsahu image. Zpráva má předpřipravené čtyři nadpisy: Co tato verze mění (vychází z rozdílu proti produkci), Riziko (co tato verze dokáže a předchozí nedokázala, například nové odchozí spojení, nová data nebo práh zapsaný v kódu místo v konfiguraci), Ověřeno (co auditor přečetl nebo spustil, a to tak podrobně, aby se to dalo zopakovat) a Neověřeno (všechno ostatní). Zprávu může navrhnout programovací agent, za její tvrzení ale odpovídá auditor.

Tlačítka Approve a Request changes jsou na konci zprávy, horní lišta nabízí Audit report nebo Propose a new version. Obě cesty zprávu uloží, znovu ji načtou a zapíšou spolu s verdiktem. Při povýšení verze do ostrého provozu se zapíšou verdikty, které ji uvolnily, a daný image už další podpisy nepřijímá. Pozdější názor tak nemůže zpětně přepsat, na základě čeho byla dřívější verze schválena. Auditor, který najde problém, ho může opravit a nasadit přímo z auditní kopie. Tím vznikne nová verze ve vývojovém prostředí, která projde sestavením, kontrolami, testovacím prostředím, vlastním zmrazením a vlastním podpisem.

Klíčová fakta

• Testovací prostředí může zmrazit jen auditor nebo admin. Zmrazení uzamkne pevný tag image a zavře cestu z vývojového prostředí do testovacího.
• Běžní členové nemohou povyšovat do ostrého provozu.
• Auditní pravidla vyžadují alespoň jeden podpis auditora a jediné Request changes povýšení zablokuje.
• Podpis je vázaný na otisk obsahu image, ne na auditní kopii.
• Auditní zprávy mají čtyři nadpisy: Co tato verze mění, Riziko, Ověřeno, Neověřeno.
• Po povýšení do ostrého provozu už vydaný image žádné další verdikty nepřijímá.
• Oprava z auditní kopie se stává novou verzí, která potřebuje vlastní zmrazení a vlastní podpis.
• Každé zmrazení, změna pravidel a verdikt se commitují do bitswan.yaml v git repozitáři daného procesu, s uvedením auditora, který je provedl, do historie, která připouští jen fast-forward, a se zprávou přesně v podepsaném znění.
• Jakmile auditovaný image dorazí do ostrého provozu, testovací prostředí se samo rozmrazí.

Jak se používá

1. Jako auditor zmrazte uzel Staging (Freeze), a tím uzamkněte prověřovaný image.
2. Otevřete Audits a zvolte Open the code for auditing. Dostanete kopii přesně této verze.
3. Projděte rozdíl proti produkci a zdrojový kód, zapojte programovacího agenta a vyplňte záložku Audit report.
4. Ve zprávě zvolte Approve nebo Request changes, případně problém opravte a nasaďte, čímž navrhnete novou verzi.
5. Jakmile jsou auditní pravidla splněná, odemkne se Promote to Production.

Proč na tom záleží: V záznamu nezůstává zaškrtnuté políčko, ale auditorova úvaha. Při pozdější kontrole nebo incidentu z něj proto vyčtete, co se prověřilo, co ne a na základě čeho byla verze uvolněna. Kdo změnu postaví, sám ji do provozu nepustí.

Mapování na předpisy a normy

• ISO/IEC 27001 A.5.3 — Oddělení povinností: kdo změnu postaví, nemůže ji sám uvolnit do ostrého provozu. Musí ji podepsat nezávislý auditor.
• ISO/IEC 27001 A.8.32 — Řízení změn: změny v produkci se před uvolněním prověří a schválí podle pravidel a pak se povýší beze změny.
• SOC 2 CC8.1 — Schvalování změn: změny před nasazením autorizují povinné podpisy zapsané v záznamu, ve kterém je každý zásah vidět.
• DORA čl. 9 — Ochrana a prevence: brána s nezávislým podpisem omezuje riziko, které změna představuje pro kritické funkce.

Historie nasazení a Inspect

Historie nasazení (Deployment history) je v Bailey verzovaný auditní záznam, do kterého jde jen přidávat. Zachycuje každé nasazení, povýšení, přepnutí, zálohu, obnovu, událost retence i změnu firewallu a ukazuje, kdo co nasadil, kdy a z jakého commitu. Přes Inspect otevřete kterékoli zaznamenané nasazení i s jeho soubory, rozdíly, platnými tajemstvími a sestaveným image.

Historie se odvozuje z verzovaného záznamu, takže ji nejde potichu upravit. Její integritu drží kanonická hlavní větev (main), která je chráněná a přijímá jen fast-forward merge. Každé nasazení posune main dopředu, force-push ani rebase přepisující historii nejsou možné, a do grafu commitů tedy jde jen přidávat. Záznam je proto neměnný už ze své konstrukce, nikoli jen podle směrnice, a to i vůči provozovateli.

Každá položka historie je bodem pro návrat. Roll back znovu nasadí přesně zaznamenanou verzi s jejím image beze změny a na začátek časové osy zapíše novou položku rolled back. Položky, jejichž verze už běží, jsou označené Currently deployed a žádné akce nenabízejí. Inspect má záložky Diff vs current (změny oproti tomu, co právě běží), Files (přesný strom zdrojových souborů), Secrets snapshot (sada tajemství platná při nasazení), Download image (sestavený image se svazkem schémat) a u aktuálního nasazení také Scale. V Inspect je dále Edit this version, která z uživatelovy kopie udělá tuto nasazenou verzi pomocí obnovovacího commitu nad main. Ve vývojovém prostředí je k dispozici i Revert dev to this version, která přidá do main jeden commit, a každá kopie tak návrat převezme při příští synchronizaci (Sync).

Klíčová fakta

• Historie zaznamenává nasazení, povýšení, přepnutí, zálohy, obnovy, události retence a změny firewallu.
• Main je chráněná a přijímá jen fast-forward, takže záznam o nasazeních nemůže přepsat nikdo, ani provozovatel.
• Roll back znovu nasadí zaznamenaný image beze změny a zapíše novou položku rolled back.
• Položky, které už běží, jsou označené Currently deployed a nemají žádné akce.
• Záložky Inspect: Diff vs current, Files, Secrets snapshot, Download image a u aktuálního nasazení Scale.
• Po Edit this version je kopie o jeden commit před main a za ní není o žádný. Dosavadní práce se odloží jako datovaný experiment.

Jak se používá

1. Otevřete prostředí a v něm Deployment history.
2. Projděte časovou osu událostí.
3. U starší položky stiskněte Inspect a projděte Files, Diff vs current a Download image.
4. U starší položky stiskněte Roll back a potvrzením znovu nasaďte přesně tuto verzi.
5. Chcete-li pokračovat od starší verze, stiskněte Edit this version. Ve vývojovém prostředí vrátíte sdílené prostředí zpět pro všechny tlačítkem Revert dev to this version.

Proč na tom záleží: Když auditor chce vidět důkazy, má je o jednu záložku dál. Že stopu nejde zfalšovat, zaručuje ochrana větve, ne slib. Návrat po špatné změně je otázkou jednoho kliknutí a potvrzení a zapíše se i samotná obnova.

Mapování na předpisy a normy

• ISO/IEC 27001 A.8.15 — Logování (integrita a ochrana proti manipulaci): provozní události se zapisují do chráněné větve main, která přijímá jen fast-forward. Jde do nich jen přidávat a přepsat je nemůže nikdo, ani provozovatel.
• DORA čl. 13 — Učení se a další rozvoj: úplný záznam podporuje rozbor po incidentu.
• NIS2 čl. 21 odst. 2 písm. b) — Zvládání incidentů: z auditní stopy lze přesně zrekonstruovat, co se stalo.
• SOC 2 CC8.1 — Řízení změn: každá změna je zaznamenaná i s rozdílem a konfigurací, která v danou chvíli platila.

Správa tajemství pro každé prostředí

Tajemství (Secrets) jsou v Bailey vázaná na prostředí. Ve všech prostředích mají stejné názvy, ale v každém jiné hodnoty. Kdo je smí zapisovat, určuje role. Do aplikace se vkládají při nasazení a s každým nasazením se ukládá jejich snímek. Do repozitáře se nikdy nezapisují.

Jako tajemství prostředí se ukládají přístupové údaje, třeba klíče k platební bráně, i konfigurační hodnoty, například limity pro schvalování. Klíč a hodnotu přidáte přímo v konzoli a při příštím nasazení daného prostředí se vloží do aplikace. Každé nasazení si uloží sadu tajemství, která v tu chvíli platila, takže Inspect u kteréhokoli dřívějšího nasazení přesně ukáže, s jakými tajemstvími běželo.

Klíčová fakta

• Názvy tajemství jsou společné pro všechna prostředí, hodnoty má každé prostředí vlastní.
• Členové tajemství číst mohou, zapisovat je smějí admini a auditoři.
• Tajemství se vkládají při nasazení a do repozitáře se nikdy necommitují.
• Každé nasazení si ukládá snímek své sady tajemství, který v Inspect najdete jako Secrets snapshot.

Jak se používá

1. Otevřete prostředí a v něm Secrets.
2. Přidejte klíče i s hodnotami.
3. Hodnoty se vloží při příštím nasazení daného prostředí a nikdy se necommitují.
4. Každé nasazení si uloží snímek platné sady tajemství.

Proč na tom záleží: Tajemství nezůstávají ve zdrojovém kódu ani v konverzacích v chatu a sadu tajemství kteréhokoli nasazení lze zpětně prověřit.

Mapování na předpisy a normy

• ISO/IEC 27001 A.8.24 — Použití kryptografie a správa tajemství: tajemství se bezpečně ukládají a vkládají odděleně od zdrojového kódu.
• NIS2 čl. 21 odst. 2 písm. h) — Kryptografie a případně šifrování: s citlivými údaji se jako s citlivými zachází už ve výchozím nastavení.
• GDPR čl. 32 — Zabezpečení zpracování: přístupové údaje, které chrání osobní údaje, nejsou ve zdrojovém kódu a přístup k nim řídí role.

Kontejnery: co v prostředí skutečně běží

Pohled Containers v Bailey vypíše každou službu nasazenou v prostředí jako skutečně běžící kontejner s jeho aktuálním stavem. U každého kontejneru zvlášť nabízí Logs, Inspect a ovládání pro restart a zastavení. Provozovatel tu vidí, co prostředí doopravdy spouští.

Zobrazený stav hlásí sám kontejner, nejde o to, co se zamýšlelo. Služba, která pořád padá a znovu startuje, se ukáže jako Restarting, nikdy jako běžící, a uvidíte i to, kolikrát ji Docker restartoval. Dva restarty během nasazení a dvacet tisíc restartů jsou totiž úplně jiné situace. Stejný počet ukazuje u každého kontejneru i Inspect. Jednotlivou službu lze restartovat nebo zastavit, aniž by se to dotklo ostatních. Když provozovatel stiskne Restart, objeví se vedle služby v tomto seznamu, na kartě prostředí i v pipeline točící se kolečko. Zmizí teprve tehdy, když Bailey uvidí, že kontejner zase běží, ne už ve chvíli, kdy byl požadavek přijat. Záměrný restart si tak nikdo nesplete s kontejnerem, který opakovaně padá. V prostředí Disaster Recovery odkazuje každý kontejner na vlastní instanci záložního slotu, takže provozovatel pracuje s obnovenou aplikací, ne s tou v ostrém provozu.

Klíčová fakta

• Každý kontejner ukazuje svůj skutečný stav. Služba, která pořád padá, se hlásí jako Restarting i s počtem restartů.
• Počet restartů je vidět také v Inspect.
• Logs, Inspect, restart i zastavení fungují pro každý kontejner zvlášť.
• Restart spuštěný uživatelem ukazuje točící se kolečko, dokud Bailey nezjistí, že kontejner zase běží.
• V prostředí Disaster Recovery odkazují kontejnery na instance záložního slotu.

Jak se používá

1. Otevřete prostředí a v něm Containers.
2. Zkontrolujte stav jednotlivých služeb.
3. K hledání příčin použijte Logs nebo Inspect.
4. V případě potřeby restartujte nebo zastavte jednotlivý kontejner.

Mapování na předpisy a normy

• SOC 2 CC7.2 — Monitorování systému: stav kontejnerů je vidět u každé služby v každém prostředí.
• DORA čl. 10 — Detekce: provozovatelé vidí aktuální stav každé běžící služby.
• ISO/IEC 27001 A.8.16 — Monitorovací činnosti: co v systému běží, je vidět v reálném čase.

Zálohy a retence

Zálohy (Backups) jsou v Bailey snímky živé databáze a objektového úložiště prostředí k určitému okamžiku. Řídí je pravidla retence a zapisují se do auditní stopy. Snímek zachytí databázi, která je v modrozeleném nasazení právě aktivní, nikoli zastaralou databázi pod starým názvem.

Dialog Create snapshot se zeptá na popisek a prostředí. Po potvrzení spustí úlohu, která zachytí živou databázi i objektové úložiště a průběžně hlásí postup u každého úložiště zvlášť: Postgres, CouchDB a Garage. Hotový snímek se objeví v seznamu i s velikostí a obsahem a lze ho obnovit nebo naklonovat do jiného prostředí. Retence se nastavuje jako pravidlo, nenechává se na nahodilé plánované úloze.

Klíčová fakta

• Snímky zahrnují živou databázi i objektové úložiště.
• Postup se hlásí pro každé úložiště zvlášť: Postgres, CouchDB, Garage.
• Snímky mají popisek a uvedenou velikost a dají se obnovit i naklonovat mezi prostředími.
• Retence je nastavené pravidlo.
• Zálohy, obnovy a události retence se objevují v historii nasazení.

Jak se používá

1. Otevřete Production a v něm Backups.
2. Stiskněte Create snapshot a zadejte popisek.
3. Sledujte průběh. Hotový snímek se objeví v seznamu i s velikostí a obsahem.
4. Nastavte pravidlo retence.

Mapování na předpisy a normy

• ISO/IEC 27001 A.8.13 — Zálohování informací: zálohy se pořizují, uchovávají a jejich funkčnost lze ověřit obnovou.
• DORA čl. 12 odst. 1 — Zásady a postupy zálohování: rozsah i četnost záloh jsou stanovené a vynucované.
• SOC 2 A1.2 — Zálohování: snímky živých dat se pořizují na požádání i podle pravidel.

Obnova po havárii: nácvik a obnova

Obnova po havárii (Disaster recovery) v Bailey nahraje zálohu z ostrého provozu do samostatného DR slotu, nikdy přímo do běžící produkce. Tým ji tam ověří a označí jako otestovanou obnovou. Když je potřeba, udělá Bailey z tohoto slotu ostrý provoz přepnutím vstupního bodu (ingress), bez migrace dat, bez nového nasazení a bez výpadku.

Obnova do DR slotu průběžně hlásí postup u každého úložiště zvlášť a po dokončení je slot označený In DR now. Tým ho otevře a ověří, že je kompletní. Jako otestovanou obnovou lze označit jen tu zálohu, která se do DR skutečně nahrála. Záložka How it works vysvětluje modrozelené sloty a přepnutí. Pro přechod do ostrého provozu se tlačítko Restore zeptá „Make Disaster Recovery the live Production?“ a přesměruje produkční adresu na ověřený slot. Při nácviku se dialog otevře a pak zruší.

Klíčová fakta

• Zálohy se obnovují do izolovaného DR slotu, nikdy přímo do běžící produkce.
• Po dokončené obnově je slot označený In DR now.
• Jako otestovanou obnovou lze označit jen zálohu, která se do DR skutečně nahrála, a poslední úspěšný test se zapíše.
• Tlačítko Restore přepne vstupní bod (ingress) bez migrace dat, bez nového nasazení a bez výpadku.
• Záložka How it works vysvětluje sloty a přepnutí srozumitelnou řečí.

Jak se používá

1. Pořiďte snímek ostrého provozu.
2. Přejděte do Disaster Recovery a zvolte Rehearse & restore.
3. Obnovte zálohu do DR, ověřte ji a zvolte Mark recovery-tested.
4. Když je potřeba, přepněte ostrý provoz tlačítkem Restore.

Proč na tom záleží: Záloha, kterou nikdo nikdy neobnovil, není ověřená. S Bailey se nácvik obnovy stává rutinou a skutečné přepnutí je otázkou jediného kliknutí.

Mapování na předpisy a normy

• DORA čl. 11–12 — Reakce, obnova a testování obnovy: testování obnovy je rutina a poslední úspěšný test se zapisuje.
• SOC 2 A1.2 / A1.3 — Zálohování a testování obnovy: obnova se nacvičuje do izolovaného DR slotu a test se zapíše.
• ISO/IEC 27001 A.5.30 / A.8.13 — Připravenost ICT na zachování kontinuity: zálohy se ověřují obnovou do izolovaného slotu.
• NIS2 čl. 21 odst. 2 písm. c) — Řízení kontinuity provozu a krizové řízení: přepnutí bez výpadku znamená, že obnova nestojí odstávku.

Firewall pro odchozí provoz a záznamy o zpracování podle GDPR

Firewall je v Bailey seznam povolených cílů pro odchozí provoz, vedený pro každé prostředí zvlášť. Každý schválený externí server propojuje se záznamem o zpracování osobních údajů podle GDPR a nabízí schvalovací postup, verzování a uloženou smlouvu o zpracování osobních údajů (DPA). V testovacím prostředí i v ostrém provozu je odchozí provoz ve výchozím stavu zakázaný.

Když prostředí hlídá brána pro odchozí provoz, firewall čte u každého odchozího spojení SNI nebo hlavičku Host. Ve vývojovém prostředí provoz jen sleduje a každý cíl, který na seznamu není, zařadí do Needs review, kde ho provozovatel schválí, nebo zamítne. Schválení serveru otevře jeho záznam o zpracování. Provozovatel nejprve uvede, zda se tam posílají nějaká uživatelská nebo osobní data. Pokud ano, formulář zaznamená, jaká data odcházejí, za jakým účelem, zda se v cíli ukládají (No, Transient nebo Yes), jurisdikci zpracovatele a podepsanou smlouvu o zpracování jako PDF. Uložením záznamu se server povolí. Záznamy o činnostech zpracování podle čl. 30 GDPR a složka smluv se zpracovateli podle čl. 28 tak vznikají průběžně, jak se systém provozuje.

Klíčová fakta

• Odchozí spojení se rozpoznávají podle SNI nebo hlavičky Host.
• V testovacím prostředí i v ostrém provozu je odchozí provoz ve výchozím stavu zakázaný. Vývojové prostředí provoz sleduje a servery mimo seznam zařazuje do Needs review.
• Schválení otevře záznam o zpracování dřív, než je server povolen.
• Zaznamenané údaje: zda se posílají osobní údaje, jaká data, účel, ukládání (No, Transient, Yes), jurisdikce zpracovatele a podepsaná smlouva DPA (PDF).
• Server se povolí teprve tehdy, když je jeho záznam uložený tlačítkem Approve & record.
• Změny firewallu se objevují v historii nasazení.

Jak se používá

1. Otevřete prostředí a v něm Firewall a počkejte, až načte aktuální nastavení.
2. V Needs review najděte cílový server a stiskněte Approve.
3. Odpovězte na „No user data?“, nebo vyplňte, jaká data, účel, zda se ukládají a jurisdikci.
4. Přiložte smlouvu DPA se zpracovatelem (PDF) a stiskněte Approve & record.

Proč na tom záleží: Každý externí příjemce dat se zapíše i s účelem a smlouvou ve chvíli, kdy je povolen. Záznamy o činnostech zpracování a smlouvy se zpracovateli tak vznikají jako vedlejší produkt provozu systému, žádná zvlášť vedená tabulka není potřeba.

Mapování na předpisy a normy

• GDPR čl. 30 — Záznamy o činnostech zpracování: každý externí příjemce se zapíše i s účelem a s informací, zda se mu předávají osobní údaje.
• GDPR čl. 28 — Povinnosti zpracovatele: u každého serveru, který zpracovává osobní údaje, je smlouva o zpracování uložená dřív, než se odchozí provoz povolí.
• NIS2 čl. 21 odst. 2 písm. a) — Analýza rizik a zásady bezpečnosti sítí: odchozí provoz je ve výchozím stavu zakázaný a výjimky jsou prověřené a zdokumentované.
• ISO/IEC 27001 A.8.20–8.21 — Bezpečnost sítí a síťových služeb: odchozí spojení se řídí pro každou službu zvlášť.

Bezpečnost dodavatelského řetězce a SBOM

Bezpečnost dodavatelského řetězce (Supply chain) v Bailey dává každému nasazenému image soupis softwarových komponent (SBOM) a sken známých zranitelností (CVE). Zranitelnosti řadí podle závažnosti, každou propojí s příslušnými bezpečnostními upozorněními a přijatá rizika zapisuje do zdrojového kódu. Skenuje se ten image, který se skutečně nasazuje.

Pohled Supply chain ukazuje každou zranitelnost i s dotčeným balíčkem. Po otevření CVE vedou odkazy na upozornění v osv.dev, NVD a GitHubu. Rozhodnutí, že něco nespadá do rozsahu, je výslovné, má uvedeného autora a ukládá se do stromu zdrojových souborů daného procesu. Záložka Supply chain v ostrém provozu tato rozhodnutí zobrazuje jen pro čtení, takže auditoři vidí, co bylo vyřazeno, kým a proč.

Klíčová fakta

• Každý nasazený image má svůj SBOM.
• Zranitelnosti jsou seřazené podle závažnosti a ukazují dotčený balíček.
• Každé CVE odkazuje na upozornění v osv.dev, NVD a GitHubu.
• Rozhodnutí o vyřazení z rozsahu se ukládají do zdrojového kódu s uvedeným autorem a v ostrém provozu jsou vidět jen pro čtení.
• Skenuje se image, který se nasazuje, ne nějaké starší sestavení.

Jak se používá

1. Otevřete prostředí a v něm Supply chain.
2. Seřaďte zranitelnosti podle závažnosti a otevřete CVE s jeho upozorněním.
3. Případné rozhodnutí o vyřazení z rozsahu zapište přímo do repozitáře.

Mapování na předpisy a normy

• NIS2 čl. 21 odst. 2 písm. d) — Bezpečnost dodavatelského řetězce: soupis toho, z čeho se běžící software skládá, lze kdykoli předložit.
• SOC 2 CC7.1 — Odhalování zranitelností: SBOM i sken CVE se dělají nad image, který se skutečně nasazuje.
• ISO/IEC 27001 A.5.7 / A.8.8 — Informace o hrozbách a řízení technických zranitelností: známé zranitelnosti v závislostech jsou neustále na očích.

Lidé, role a oddělení povinností

People & roles je stránka konzole Bailey se seznamem lidí na serveru. Každý z nich má výslovně přidělenou roli (admin, auditor nebo member) a vlastní seznam důvěryhodných zařízení, která lze schválit nebo odebrat. Role Bailey čte z vlastního úložiště uživatelů a rolí a vynucuje je na serveru, nejen tím, že v uživatelském rozhraní skryje ovládací prvky.

Tři role si pravomoci dělí záměrně. Admin (provozovatel) má všechna práva. Member (člen) dělá každodenní práci, tedy staví a nasazuje, ale nastavení správy a dohledu měnit nemůže. Role auditora není jen ke čtení. Auditor může prověřit všechno a k tomu má ovládací prvky, které potřebuje ten, kdo odpovídá za soulad s předpisy: nastavuje, jak často se testuje obnova, a schvaluje záznam o zpracování podle GDPR u serveru, na který smí produkce odchozím provozem přistupovat. Pipeline ale auditor ovládat nemůže. Nenasazuje ani nepovyšuje kód, nespravuje lidi, role ani zařízení a nemá přístup do administrátorského nastavení serveru.

Právě toto rozdělení je oddělení povinností, které auditor stvrzuje. Kdo nastavuje četnost testů obnovy a prověřuje nového příjemce dat, záměrně není tím, kdo nasazuje kód. Na stránce People & roles se také schvalují čekající zařízení a odebírají ztracená.

Klíčová fakta

• Bailey má tři role: admin (provozovatel), auditor a member (člen).
• Role se čtou z vlastního úložiště uživatelů a rolí v Bailey a vynucují se na serveru, nejen skrytím v rozhraní.
• Admin má na serveru všechna práva.
• Member dělá každodenní práci, staví a nasazuje, ale nastavení správy a dohledu měnit nemůže.
• Auditor může prověřit všechno, nastavit četnost testů obnovy a schválit záznam o zpracování podle GDPR u serveru, na který smí produkce odchozím provozem přistupovat.
• Auditor nemůže nasazovat ani povyšovat kód, spravovat lidi, role ani zařízení ani měnit administrátorské nastavení serveru.
• Důvěryhodná zařízení jednotlivých lidí se schvalují (podle kódu) i odebírají na téže stránce People & roles.
• Díky tomuto rozdělení má pravomoc nad správou a dohledem jiný člověk než ten, kdo smí nasazovat kód.

Jak se používá

1. V konzoli otevřete People & roles.
2. Zkontrolujte role v celém týmu.
3. Čekající zařízení schvalte podle jeho kódu.
4. Když lidé přicházejí a odcházejí, odeberte zařízení nebo změňte roli.

Proč na tom záleží: Auditor má v Bailey dohled se skutečnou pravomocí nad nastavením souladu s předpisy, tato pravomoc je ale záměrně oddělená od pravomoci nasazovat kód. Každá role dostane jen ta práva, která její úkoly vyžadují, a přesně to chtějí opatření pro řízení přístupu a oddělení povinností.

Mapování na předpisy a normy

• ISO/IEC 27001 A.5.18 / A.5.3 — Přístupová práva a oddělení povinností: admin, auditor a member jsou samostatné role vynucované na serveru a pravomoc auditora nad správou a dohledem je oddělená od pravomoci členů stavět a nasazovat.
• SOC 2 CC6.2 / CC6.3 — Přidělování a odebírání přístupu: role i důvěryhodná zařízení jednotlivých lidí se přidělují a odebírají centrálně.
• NIS2 čl. 21 odst. 2 písm. i) — Bezpečnost lidských zdrojů a řízení přístupu: přístup se řídí rolemi a dá se kdykoli prověřit.
• DORA čl. 9 odst. 4 — Řízení přístupu podle zásady nezbytně nutné znalosti: auditoři mají správu a dohled (četnost testů obnovy, schvalování záznamů o zpracování), ale nenasazují ani nepovyšují. Členové nasazují, ale nastavení správy a dohledu měnit nemohou.

Jednotné přihlášení přes vlastního poskytovatele identit

Jednotné přihlášení (Single sign-on, SSO) v Bailey umožňuje adminovi připojit k serveru Bailey vlastního poskytovatele identit organizace přes OpenID Connect (OIDC), vedle účtů Bitswan. O tom, kdo ve firmě pracuje, dál rozhoduje firemní adresář. O tom, co kdo smí dělat, dál rozhoduje Bailey.

Ve výchozím stavu se lidé do Bailey přihlašují účtem Bitswan, který vydává Automation Operations Centre (AOC). Zavedená organizace ale obvykle už svého poskytovatele identit má, odchody zaměstnanců řeší přes něj a další místo, kde by se zakládaly účty zaměstnanců, nechce. Po nastavení jednotného přihlášení se lidé přihlašují účtem, který už mají. V adresáři jsou už všichni, kdo mají mít přístup, takže pozvánky e-mailem nejsou potřeba. Když někoho centrálně zablokujete v adresáři, zavře se mu tím i cesta do Bailey.

Ve výchozím stavu zůstávají otevřené obě cesty. Přihlašovací stránka nabídne volbu, takže účty Bitswan (účet provozovatele i účty spravované přes AOC) na stejném serveru fungují dál. Je to záměrná pojistka: poskytovatel, kterému vypršel certifikát, nesmí zamknout všechny administrátory mimo stroj, na kterém by to mohli opravit. Organizace může účty Bitswan vypnout, a její poskytovatel pak bude jedinou cestou dovnitř. Zbude jediný konektor, nikdo nic nevybírá a přihlášení vede rovnou k poskytovateli. Pokud pak má poskytovatel výpadek, propadlý certifikát nebo vyměněný klientský klíč (client secret), přijdou o přístup do konzole všichni, včetně toho, kdo by to měl opravit. Obnova přitom nevede přes prohlížeč. Provozovatel s přístupem do shellu na serveru spustí bitswan bailey sso disable, čímž obnoví přihlašování účty Bitswan a znovu sestaví proxy.

Automatizace fungují i po změně dál. Aplikace nasazená v Bailey ověřuje identitu u každého požadavku podle toho, kdo ji skutečně podepsal. Jakmile tedy stojí vpředu poskytovatel organizace, ověřuje aplikace právě jeho a spolu s identitou dostane i členství ve skupinách, které adresář zveřejňuje, aby podle nich mohla uplatnit vlastní pravidla přístupu. Dvě věci jednotné přihlášení záměrně nemění. Každé nové zařízení se dál schvaluje úplně stejně jako dosud. A lidé přicházejí jako členové bez zvýšených práv, dokud jim admin nepřidělí roli v People & roles nebo dokud se skupiny poskytovatele nenamapují na role v Bailey.

Klíčová fakta

• Bailey podporuje jako způsob přihlášení libovolného poskytovatele OpenID Connect. Nastavuje se v části Single sign-on v sekci Admin konzole.
• Nastavení potřebuje zobrazovaný název (popisek na přihlašovacím tlačítku), URL vydavatele (issuer) a ID klienta s klientským klíčem.
• Po stisknutí Test načte Bailey konfigurační dokument poskytovatele (discovery document) a poskytovatele, na kterého se nedostane, odmítne.
• Přihlašování účty Bitswan zůstává ve výchozím stavu zapnuté, takže se administrátoři dostanou dovnitř, i když poskytovatel selže.
• Po vypnutí účtů Bitswan je poskytovatel organizace jedinou cestou dovnitř a obrazovka s volbou zmizí.
• bitswan bailey sso disable spuštěné ze shellu na serveru obnoví přihlašování účty Bitswan a znovu sestaví proxy.
• Se SSO nejsou potřeba pozvánky e-mailem. Kdo je z adresáře vyřazen, ztratí i přístup do Bailey.
• Skupiny poskytovatele lze namapovat na role v Bailey. Bez mapování přichází každý jako člen.
• Schvalování zařízení platí i po zapnutí SSO pro každé nové zařízení.
• Nasazené aplikace ověřují každý požadavek podle skutečného podepisujícího a dostávají členství ve skupinách z adresáře.

Jak se používá

1. V sekci Admin konzole otevřete Single sign-on.
2. Zadejte zobrazovaný název poskytovatele. Ten se objeví na tlačítku, na které lidé klikají.
3. Zadejte URL vydavatele a stiskněte Test. Bailey načte konfigurační dokument a poskytovatele, na kterého se nedostane, odmítne.
4. U poskytovatele zaregistrujte adresu pro přesměrování (redirect URI), kterou stránka zobrazí, a pak sem vložte ID klienta a klientský klíč.
5. Volitelně namapujte skupiny poskytovatele na role v Bailey. Když mapování necháte prázdné, každý přijde jako člen.
6. Účty Bitswan nechte zapnuté, pokud jste si nepřečetli a nepřijali varování vedle této volby.
7. Stiskněte Enable single sign-on. Všichni přihlášení, včetně admina, se na příští otevřené stránce přihlásí znovu.

Proč na tom záleží: Organizace si ponechá jediný proces nástupů a odchodů místo souběžné databáze účtů a při přihlášení platí její vlastní pravidla ověřování, včetně požadavků na vícefaktorové ověření (MFA). Důvěra v zařízení zůstává druhým, nezávislým opatřením. A protože přihlašování účty Bitswan zůstává ve výchozím stavu k dispozici, výpadek poskytovatele identit administrátory nezamkne.

Mapování na předpisy a normy

• ISO/IEC 27001 A.5.16 — Správa identit: identity se spravují ve vlastním adresáři organizace, s jediným procesem nástupů a odchodů místo souběžné databáze účtů.
• SOC 2 CC6.1 / CC6.2 — Logický přístup a jeho přidělování: přístup vychází z firemního poskytovatele identit a jeho odebrání tam odebere i přístup do Bailey.
• NIS2 čl. 21 odst. 2 písm. i) — Zásady řízení přístupu: ověřování je svěřené zdroji identit, který má organizace pod kontrolou, a schvalování zařízení zůstává druhým, nezávislým opatřením.
• DORA čl. 9 odst. 4 — Silné ověřování: při přihlášení platí vlastní pravidla ověřování organizace včetně požadavků na MFA a důvěru v zařízení platforma dál vynucuje nezávisle.

Sdílení endpointu s lidmi a skupinami

Sdílení endpointů je v Bailey způsob, jak vlastník udělí přístup ke kterékoli chráněné aplikaci za bránou Bailey, včetně frontendů, které provozovatelé postaví a nasadí. Přístup je ve výchozím stavu zakázaný. Endpoint otevřou jen lidé, které vlastník pozve, a každé oprávnění jmenuje konkrétního člověka nebo skupinu a úroveň (User nebo Owner), aniž by se dotklo přístupu kohokoli jiného.

Frontend nasazené automatizace je sám o sobě endpointem chráněným Bailey. Po otevření ho obalí rozhraní Bailey a vlastník v něm najde tlačítko Share. Vlastník udělí přístup člověku (podle e-mailu) nebo celé skupině u poskytovatele identit a zvolí úroveň User (otevřít a používat), nebo Owner (navíc spravovat, kdo další má přístup). U každého oprávnění se zapíše, kdo ho udělil a kdy. Uživatel, kterého brána odmítne, může o přístup požádat a žádost se zobrazí vlastníkovi ke schválení nebo zamítnutí.

Stejný mechanismus chrání všechno: nástěnku pracovního prostoru (workspace), gitops i každý frontend automatizace, který provozovatel vytvoří. Přidat člena do pracovního prostoru znamená udělit mu oprávnění k endpointu tohoto prostoru. Pustit kolegu do nasazené aplikace znamená udělit mu oprávnění k endpointu této aplikace. Každé oprávnění platí pro jeden endpoint a spravuje ho vlastník, takže tu není žádný všemocný admin, který by potichu četl všechno, a odebrání přístupu začne platit stejně okamžitě jako jeho udělení.

Klíčová fakta

• Každý endpoint chráněný Bailey má přístup ve výchozím stavu zakázaný.
• Nástěnky pracovních prostorů, gitops i každý nasazený frontend automatizace používají stejný mechanismus sdílení.
• Oprávnění uděluje vlastník endpointu tlačítkem Share v rozhraní Bailey, které aplikaci obaluje.
• Oprávnění může mířit na člověka podle e-mailu, nebo na skupinu u poskytovatele identit (zapsanou jako /group).
• Úrovně přístupu jsou dvě: User (otevřít a používat) a Owner (navíc spravovat, kdo další má přístup).
• U každého oprávnění se zapisuje, kdo ho udělil a kdy.
• Odmítnutí uživatelé mohou o přístup požádat a vlastník žádost schválí, nebo zamítne.
• Přístup platí okamžitě po Add a okamžitě končí po Remove.
• Neexistuje žádný všemocný admin s automatickým přístupem ke všem endpointům.

Jak se používá

1. Otevřete frontend nasazené automatizace (endpoint chráněný Bailey) a v jeho rozhraní klikněte na Share.
2. Zadejte e-mail člověka nebo /group a zvolte User, nebo Owner.
3. Stiskněte Add. Přístup platí okamžitě a zapíše se.
4. Čekající žádosti o přístup schvalte nebo zamítněte a k odebrání přístupu použijte Remove.

Proč na tom záleží: Sdílení v Bailey se řídí pro každý endpoint zvlášť, rozhoduje o něm vlastník a všechno se zapisuje. Řízení přístupu tu není centrální seznam, který někdo zapomene pročistit. O tom, kdo se k aplikaci dostane, rozhoduje veřejně a přesně její vlastník a přístup odebere ve chvíli, kdy má skončit.

Mapování na předpisy a normy

• ISO/IEC 27001 A.5.15 / A.8.3 — Řízení přístupu a omezení přístupu k informacím: přístup ke každému endpointu uděluje výslovně jeho vlastník, každému subjektu zvlášť.
• SOC 2 CC6.1 / CC6.3 — Logický přístup a přístup podle rolí: endpointy mají přístup ve výchozím stavu zakázaný a každé oprávnění nese roli a dohledatelného autora.
• NIS2 čl. 21 odst. 2 písm. i) — Řízení přístupu: kdo se dostane ke které službě, je výslovně určené, spravuje to vlastník a dá se to odebrat.
• GDPR čl. 5 odst. 1 písm. f) / čl. 32 — Integrita a důvěrnost: k osobním údajům za endpointem se dostanou jen subjekty, kterým byl přístup výslovně udělen.

Export bezpečnostního auditního záznamu do SIEM

Export do SIEM posílá z Bailey bezpečnostní auditní záznam serveru v reálném čase do externího systému SIEM přes OpenTelemetry (OTLP). Zahrnuje události jako změny důvěry v zařízení, změny rolí, založení pracovního prostoru a schválení přístupu. Nastavuje se na kartě SIEM forwarding na stránce Server overview.

Bailey si vlastní bezpečnostní auditní stopu vede bez ohledu na to, zda je export nastavený. Export každou bezpečnostní událost zrcadlí do externího příjemce OpenTelemetry, aby ji bezpečnostní dohledové centrum (SOC) mohlo dávat do souvislostí, spouštět nad ní upozornění a uchovávat ji spolu se vším ostatním. Ingestor URL je základní adresa OTLP kolektoru, jen hostitel a port (například https://collector.example.com). Cestu /v1/logs připojí Bailey sám. Jako Protocol se volí OTLP/HTTP (protobuf přes HTTPS, nejsnáze se směruje přes proxy), nebo OTLP/gRPC (streamovací kanál gRPC s menší režií při velkém objemu), podle toho, na čem kolektor naslouchá. Stream lze volitelně ověřit tokenem typu bearer v poli Auth token.

Stisknutím Save & connect se spustí živý test připojení, který ukáže Connected nebo přesnou chybu dřív, než se na tok dat začnete spoléhat. Karta pak ukazuje, kdy byla doručena poslední událost.

Klíčová fakta

• Bailey přeposílá bezpečnostní auditní události do SIEM přes OpenTelemetry ve chvíli, kdy nastanou.
• Exportované události zahrnují změny důvěry v zařízení, změny rolí, založení pracovního prostoru a schválení přístupu.
• Nastavení je na kartě SIEM forwarding na stránce Server overview.
• Ingestor URL obsahuje jen hostitele a port. Cestu /v1/logs připojí Bailey sám.
• Podporované protokoly jsou OTLP/HTTP (protobuf přes HTTPS) a OTLP/gRPC.
• Stream lze volitelně ověřit tokenem typu bearer (Auth token).
• Save & connect provede živý test připojení a ohlásí Connected nebo přesnou chybu.
• Karta ukazuje aktuální stav a čas doručení poslední události. Export lze upravit nebo vypnout.
• Auditní události vznikají bez ohledu na to, zda je export zapnutý.

Jak se používá

1. Otevřete Server overview a najděte SIEM forwarding.
2. Klikněte na Configure ingestor, zadejte Ingestor URL, zvolte Protocol a v případě potřeby doplňte Auth token.
3. Stiskněte Save & connect. Spojení se otestuje a zobrazí se Connected nebo chyba.
4. Sledujte aktuální stav a čas posledního doručení a podle potřeby použijte Edit nebo Disable.

Proč na tom záleží: Auditní události vznikají za všech okolností. Export do SIEM je průběžně předává do stávajícího řetězce detekce a uchovávání dat v organizaci, takže dohled i upozornění běží v nástroji, který bezpečnostní tým už používá, a ne v konzoli, kterou musí někdo nezapomenout otevřít.

Mapování na předpisy a normy

• ISO/IEC 27001 A.8.15 / A.8.16 — Logování a monitorování: bezpečnostní události lze v reálném čase exportovat do centrálního monitorování a uchovávání.
• SOC 2 CC7.2 — Monitorování systému: auditní události plní externí SIEM, kde se dávají do souvislostí a spouštějí upozornění.
• DORA čl. 10 — Odhalování neobvyklých činností: export událostí v reálném čase umožňuje průběžnou detekci v SOC.
• NIS2 čl. 21 odst. 2 písm. b) — Zvládání incidentů: centralizované exportované události zkracují dobu odhalení a usnadňují rekonstrukci.

Nástup nového kolegy (výchozí stav je zákaz)

Nástup nového kolegy má v Bailey tři kroky a výchozím stavem je zákaz přístupu. Nový kolega se přihlásí, jeho neznámé zařízení zůstane stát u brány a admin ho pustí dál, až zadá šestimístný kód, který mu kolega přečte. Samotné platné přihlášení nedává žádný přístup. Přístup je vázaný na konkrétní schválené zařízení.

Když se nový kolega přihlásí na svém notebooku k hostiteli Bailey, třeba přes firemního poskytovatele identit, přihlášení projde, ale z produktu neuvidí nic. Brána mu ukáže „Trust this device“ se zprávou „You're signed in, but this device isn't trusted yet.“ Prohlížeč zobrazí velký šestimístný kód s popiskem „Your code“, pokyn „Read this code to an admin“ a ukazatel „Waiting for an admin…“. Dokud zařízení neschválí někdo, komu už Bailey důvěřuje, není dostupný žádný pracovní prostor (workspace), aplikace ani konzole. Přístup je vázaný na hardware, nejen na přihlašovací údaje. Proto bránou neprojde uniklé nebo vylákané heslo, a dokonce ani celý napadený účet u poskytovatele identit, pokud ho útočník použije ze svého počítače.

Admin otevře v Server Console stránku People & roles (lidé a role). Žádost tam najde přímo pod jménem dotyčného jako lištu „Device awaiting approval“ s odznakem First device a údajem, jak dlouho už čeká. Server adminovi kód nikdy nepošle. Admin ho musí slyšet od dotyčného v reálném čase, osobně nebo po telefonu, a tím se ověří, že člověk u toho zařízení opravdu sedí. Admin zadá šest číslic a stiskne Trust this device. Jediný krok tak uživatele zapíše jako vlastníka zařízení a z notebooku udělá důvěryhodné zařízení, označené odznakem a odvolatelné jako každé jiné. Nic se nepouští automaticky a není tu žádné rozhodnutí o zamítnutí, na které by se dalo zapomenout: neschválená zařízení prostě vyprší.

Jakmile je zařízení důvěryhodné, čekající prohlížeč opustí stav „Waiting for an admin…“ a přesměruje člověka rovnou tam, kam se snažil dostat, bez nového přihlášení a bez dalšího kroku. Od té chvíle nese zařízení vlastní cookie s důvěrou, takže člověk může přicházet a odcházet bez dalšího schvalování. Zařízení se objeví v seznamu jako každé jiné důvěryhodné zařízení a odebírá se na stejných místech, kde bylo přijato, tedy v People & roles a Your devices (vaše zařízení). Když se notebook ztratí nebo ho někdo ukradne, případně když člověk z firmy odejde, admin zařízení (nebo celého člověka) odvolá. Přístup ke konzoli i ke všem aplikacím v pracovním prostoru tím okamžitě skončí a nikdo nemusí měnit hesla v desítkách aplikací.

Klíčová fakta

• Úspěšné přihlášení do Bailey ještě nedává přístup, nedůvěryhodné zařízení zůstane stát u brány.
• Čekající zařízení zobrazí šestimístný kód, výzvu „Read this code to an admin“ a „Waiting for an admin…“.
• Server schvalujícímu adminovi kód nikdy neukáže. Admin ho musí slyšet od dotyčného, a tím ověří jeho přítomnost.
• Čekající žádosti se v People & roles zobrazují jako lišta „Device awaiting approval“ s odznakem First device a dobou čekání.
• Jediný krok, Trust this device, uživatele zapíše a zároveň zařízení označí jako důvěryhodné.
• Nic se nepouští automaticky. Neschválená zařízení vyprší, takže je není třeba výslovně zamítat.
• Důvěryhodné zařízení projde hned, bez nového přihlášení, a nese vlastní cookie s důvěrou.
• Důvěra platí pro jednotlivá zařízení. Každý pracuje ze svého vlastního důvěryhodného hardwaru.
• Odvolání zařízení nebo člověka v People & roles okamžitě ukončí přístup ke konzoli i ke všem aplikacím v pracovním prostoru.
• Ukradený účet u poskytovatele identit nejde na počítači útočníka schválit, protože útočník nemůže kód předat osobně.

Jak se používá

1. Nový kolega se na svém zařízení přihlásí k hostiteli Bailey.
2. Brána ukáže Trust this device: kolega je přihlášený, ale zařízení zatím není důvěryhodné, zobrazí šestimístný kód a čeká.
3. Admin otevře People & roles a najde lištu Device awaiting approval nového kolegy.
4. Admin požádá kolegu, aby mu přečetl šestimístný kód z obrazovky, a zadá ho.
5. Admin stiskne Trust this device. Člověk je zapsaný a zařízení důvěryhodné.
6. Čekající zařízení projde okamžitě a přesměruje rovnou tam, kam má člověk přístup, bez nového přihlášení.
7. Zařízení se od té chvíle zobrazuje v seznamu, s odznakem a s možností odvolání.
8. Při ztrátě zařízení nebo odchodu zaměstnance odeberte zařízení (nebo člověka) v People & roles. Přístup se okamžitě odvolá všude.

Proč na tom záleží: Platné přihlášení ještě není přístup. Bailey váže důvěru na zařízení a pustí ho dál, jen když ho přijme přítomný důvěryhodný admin. Ze „schválení žádosti“ se tak stává „potvrzení, že u konkrétního zařízení sedí přítomný a identifikovaný člověk“, a vzdálený útočník, který má jen ukradené přihlašovací údaje, schválení nezíská. Nástup i odchod zaměstnance se ovládají stejnou pákou, jen opačným směrem. Ukradený notebook nebo odcházející kolega znamená jedno kliknutí, kterým zařízení odeberete, a žádné hromadné resetování hesel.

Mapování na předpisy a normy

• NIS2 čl. 21 odst. 2 písm. j) — Vícefaktorové ověřování a zabezpečený přístup: důvěryhodné zařízení je druhý faktor vázaný na hardware. Přijmout ho může jen admin, kterému už Bailey důvěřuje, po potvrzení kódu jiným kanálem, a odvolat ho lze pro každé zařízení i každého člověka zvlášť.
• ISO/IEC 27001 A.5.15 / A.8.5 — Řízení přístupu a bezpečná autentizace: ve výchozím stavu je přístup zakázaný a uděluje se pro konkrétní zařízení, nikoli pro přihlašovací údaje.
• ISO/IEC 27001 A.5.16 / A.5.18 — Správa identit a přístupových práv: zapsání uživatele a zařízení je výslovný, autorizovaný a zaznamenaný úkon.
• ISO/IEC 27001 A.5.15 / A.8.1 — Řízení přístupu a koncová zařízení uživatelů: důvěra v jednotlivá zařízení se uděluje, označuje i odvolává z jednoho místa.
• SOC 2 CC6.1 — Zabezpečení logického přístupu: nový uživatel zůstane u brány, dokud ho někdo výslovně neautorizuje.
• SOC 2 CC6.2 / CC6.3 — Přidělování a odebírání přístupu: novému uživateli a zařízení uděluje přístup centrálně oprávněný admin s ověřením přítomnosti a stejně rychle jde zařízení odvolat, když se ztratí nebo když člověk odchází.
• DORA čl. 9 odst. 3 — Mechanismy silného ověřování: robustní řízení přístupu zastaví každé nové zařízení dřív, než se dostane k systému.
• DORA čl. 9 odst. 4 — Přístup podle zásady nezbytně nutné znalosti: přístup uděluje admin vědomě, nevyplývá automaticky z přihlášení.
• DORA čl. 9 — Ochrana a prevence: okamžité odvolání zařízení zastaví riziko ztraceného zařízení i odcházejícího zaměstnance.

Správa paměti a pool na vyžádání

Správa paměti v Bailey drží paměť hostitele vyhrazenou pro služby, které musejí běžet stále. Všechny ostatní služby se mohou uspat až na nulu, buď automaticky při nedostatku paměti, nebo na vyžádání tlačítkem Sleep, a při prvním přístupu se zase probudí. Uživatelé tak mohou provozovat libovolné množství náhledů a procesů a kritickým úlohám přitom paměť nevezmou, ať už spí vývojový náhled, nebo služba z ostrého provozu.

Každá automatizace deklaruje v automation.toml dvě nastavení: memory-reservation (svůj paměťový rozpočet v MB) a memory_reservation_policy. Ta má hodnotu buď always-on, pro backend, který se nesmí zastavit, protože na pozadí zpracovává práci, nebo on-demand (výchozí), pro všechno, co se smí při nečinnosti pozastavit a při přístupu probudit. Démon Bailey čte tyto hodnoty z běžících kontejnerů a vede jediný rozpočet: paměť hostitele minus systémová rezerva, minus rezerva na infrastrukturu každého pracovního prostoru, minus všechny rezervace always-on a minus pool na vyžádání odpovídající velikosti.

Pool na vyžádání je dimenzovaný tak, aby současně utáhl několik největších služeb na vyžádání. Roste jen tehdy, když někdo nasadí opravdu velkou službu. Malé nečinné procesy proto žádnou vyhrazenou paměť nespotřebují a neomezený počet zřídka používaných procesů nestojí nic. Když běžící služby na vyžádání pool přesáhnou, Bailey vypne ty, které se nejdéle nepoužily. Až je někdo příště otevře, uvidí načítací obrazovku a za pár sekund služba zase běží. Povýšení a nové pracovní prostory, které by se do vyhrazeného rozpočtu nevešly, Bailey odmítne předem a přesně uvede, kolik paměti chybí. Každý kontejner, který svou rezervaci přeroste, vyvolá událost v SIEM a na své záložce Containers se označí červeně.

Stránka Resource management v Server Console ukazuje všechny procesy seskupené podle procesu a prostředí, s průběžnými součty včetně procesů, které už spí. U každého procesu nabízí tlačítko Sleep a pro celou stránku tlačítko Sleep all on-demand. Uspání je skutečné škálování na nulu: zruší se workery i sdílená brána pro odchozí provoz, takže pozastavený proces nestojí nic. Služby always-on tlačítko ignorují. Probouzení funguje všude: služby na vyžádání ve vývojovém, testovacím i produkčním prostředí se při prvním přístupu vrátí za krátkou načítací stránkou. Obnoví se z nasazeného zdroje pravdy, takže neexistuje žádná evidence uspaných služeb, která by se mohla ztratit.

Klíčová fakta

• Každá automatizace deklaruje v automation.toml hodnoty memory-reservation (MB) a memory_reservation_policy.
• Existují dvě politiky: always-on (nikdy se nezastaví) a on-demand (výchozí; při nečinnosti se pozastaví a při přístupu probudí).
• Rozpočet Bailey je paměť hostitele minus systémová rezerva, rezerva na infrastrukturu každého pracovního prostoru, všechny rezervace always-on a pool na vyžádání.
• Pool na vyžádání je dimenzovaný na několik největších služeb na vyžádání a roste jen při nasazení opravdu velké služby.
• Při nedostatku paměti Bailey vypíná služby na vyžádání, které se nejdéle nepoužily.
• Povýšení a nové pracovní prostory, které se nevejdou do vyhrazeného rozpočtu, Bailey odmítne a přesně uvede, kolik chybí.
• Kontejner, který přesáhne svou rezervaci, vyvolá událost v SIEM a na záložce Containers se označí červeně.
• Resource management nabízí Sleep u každého procesu a Sleep all on-demand. Služby always-on ho ignorují.
• Sleep zruší workery i sdílenou bránu pro odchozí provoz, takže spící proces nestojí nic.
• Spící služby ve vývojovém, testovacím i produkčním prostředí se při prvním přístupu probudí za krátkou načítací stránkou.

Jak se používá

1. V automation.toml deklarujte memory-reservation (a u workeru na pozadí také memory_reservation_policy = "always-on").
2. V Server Console otevřete Resource management. Uvidíte rozpočet hostitele, rozpis vyhrazené paměti a využití jednotlivých procesů seskupené podle procesu a prostředí.
3. Povyšte verzi nebo založte pracovní prostor. Bailey ho přijme, jen pokud se vejde do vyhrazeného rozpočtu, jinak oznámí, kolik paměti chybí.
4. Stiskněte u procesu Sleep (nebo Sleep all on-demand) a proces se okamžitě uspí na nulu. Nečinné procesy, na které nikdo nesáhne, se při nedostatku paměti vypnou i tak.
5. Otevřete spící proces (ve vývojovém, testovacím nebo produkčním prostředí) a ten se automaticky probudí za krátkou načítací stránkou.
6. Sledujte červené označení překročené rezervace na záložce Containers. Objeví se také v proudu událostí SIEM.

Proč na tom záleží: Backendy always-on mají paměť zaručenou. Všechno ostatní žije v ohraničeném poolu, který se uspí na nulu na vyžádání nebo při nedostatku paměti a při prvním přístupu se probudí. Ani rušný pracovní prostor plný experimentů tak nikdy nemůže ostrému provozu vzít paměť.

Mapování na předpisy a normy

• ISO/IEC 27001 A.8.6 — Řízení kapacit: paměť se vyhrazuje, rozpočítává a přijímání nových služeb se řídí podle aktuálního stavu hostitele. Překročení se odhalí a ohlásí.
• SOC 2 A1.1 — Dostupnost: kritické úlohy (always-on) si vyhrazenou kapacitu ponechají a méně důležité se při nedostatku paměti uspí, aniž by přišly o svůj stav.
• NIS2 čl. 21 odst. 2 písm. c) — Kontinuita činností a kapacita: nedostatek prostředků se řeší automaticky, takže nezbytné služby zůstávají dostupné.
• DORA čl. 9 — Výkon a kapacita: limity prostředků IKT jsou řízené a sledované a když úloha překročí svůj rozpočet, přijde upozornění.

Aktualizace Bailey a návrat k předchozí verzi

Aktualizace se v Bailey dělají jedním kliknutím, zaznamenávají se a dají se vrátit. Každá součást sama hlásí, když zaostává. Pracovní prostor i samotný automatizační server se na nejnovější verzi převedou jedním tlačítkem. Každá aktualizace se zapíše i s tím, kdo co na jakou verzi převedl a kdy, a kteroukoli ze tří posledních zaznamenaných verzí lze jedním kliknutím obnovit.

Bailey porovnává tagy obrazů, které jednotlivé pracovní prostory skutečně provozují, s nejnovějšími tagy v jejich vydávací řadě a běžící binárku serveru s nejnovějším zveřejněným vydáním. Vlastník pracovního prostoru vidí v administraci Bailey na jeho kartě odznak Update available. Admin vidí v navigaci položku Updates s malou bublinou, kdykoli je některá součást zastaralá. Nic se neodvozuje z názvů ani neodhaduje. Aktualizace se nabídne, jen když Bailey dokáže přečíst nasazený tag a dohledat ten nejnovější, takže odznak vždy uvádí přesné verze, které porovnává.

Pohled Updates ukazuje aktuální verzi automatizačního serveru vedle nejnovějšího vydání a vypisuje všechny pracovní prostory, pro které je k dispozici aktualizace, každý s vlastním tlačítkem Update. Aktualizace pracovního prostoru znovu vygeneruje jeho nasazení na nejnovějších tazích a nasadí ho. Při aktualizaci serveru si démon stáhne oficiální binárku z Automation Operations Centre (AOC), ve kterém je server registrovaný (ze stejného zdroje jako jednořádkový instalátor), atomicky ji na hostiteli vymění a restartuje se do nové verze. Konzole se sama znovu připojí. Není k tomu potřeba žádný shell ani příkaz na hostiteli.

Každá aktualizace serveru nebo pracovního prostoru se zapíše do evidence verzí: kdo ji provedl, kdy a přesně z jaké verze na jakou. Evidence je na stejné stránce jako Update history a zároveň se posílá do SIEM. Každá aktualizace si stav, který nahradila, ponechá jako bod obnovy, takže Roll back vrátí server nebo pracovní prostor na kteroukoli ze tří posledních zaznamenaných verzí (předchozí binárku serveru, nebo předchozí nasazení pracovního prostoru, beze změny). Samotný návrat se zapíše jako nový záznam „rolled back“. Okno je záměrně omezené na tři verze, aby historie bodů obnovy nerostla do nekonečna.

Klíčová fakta

• Bailey porovnává běžící tagy obrazů pracovních prostorů s nejnovějšími v jejich vydávací řadě a binárku serveru s nejnovějším zveřejněným vydáním.
• Vlastníci vidí na kartě pracovního prostoru odznak Update available, admini bublinu u položky Updates v navigaci.
• Aktualizace se nabídne, jen když lze dohledat nasazenou i nejnovější verzi, a odznak uvádí obě.
• Aktualizace pracovního prostoru znovu vygeneruje nasazení na nejnovějších tazích a nasadí ho.
• Aktualizace serveru stáhne oficiální binárku z AOC, ve kterém je server registrovaný, atomicky ji vymění a restartuje.
• Aktualizace nevyžadují přístup do shellu ani k CLI.
• Každá aktualizace se zapíše i s tím, kdo, kdy a z jaké přesné verze na jakou, zobrazí se v Update history a pošle do SIEM.
• Roll back jedním kliknutím obnoví kteroukoli ze tří posledních zaznamenaných verzí a i samotný návrat se zapíše.

Jak se používá

1. Sledujte bublinu u položky Updates v navigaci (admini) nebo odznak Update available na kartě pracovního prostoru (vlastníci).
2. Otevřete Updates. Uvidíte aktuální a nejnovější verzi serveru a pracovní prostory, které zaostávají.
3. Tlačítkem Update u pracovního prostoru ho převedete na nejnovější verzi řady a znovu nasadíte. Tlačítkem Update u serveru aktualizujete samotný automatizační server.
4. V Update history zjistíte, kdo co aktualizoval, na jakou verzi a kdy. Stejný záznam dostane i SIEM.
5. Pokud se aktualizace nepovede, stiskněte Roll back u kterékoli ze tří posledních zaznamenaných verzí. I návrat se zapíše.

Proč na tom záleží: Každá aktualizace v Bailey si stav, který nahradila, ponechá jako bod obnovy. Verze, na které server nebo pracovní prostor běžel, je tak vždy na jedno kliknutí a zotavení z nepovedené změny má auditní stopu, místo aby se řešilo ve spěchu.

Mapování na předpisy a normy

• ISO/IEC 27001 A.8.8 — Řízení technických zranitelností: zastaralé součásti jsou vidět a záplatují se na prověřenou nejnovější verzi, s řízenou cestou zpět.
• SOC 2 CC8.1 — Řízení změn: změny verzí jsou viditelné, provádějí se vědomě a dají se vrátit.
• NIS2 čl. 21 odst. 2 písm. e) — Zvládání zranitelností a záplatování: součásti samy hlásí, když zaostávají, a aktualizují se z důvěryhodného zdroje.

Zrcadlení zdrojového kódu a možnost odchodu (bez uzamčení u dodavatele)

Zrcadlo do vzdáleného gitového repozitáře (Git remote) posílá z Bailey všechno, co pracovní prostor obsahuje, tedy kód každého procesu, jeho specifikaci, výjimky z CVE a manifesty nasazení, do repozitáře, který má pod kontrolou zákazník. Zdrojový kód tak nikdy nezůstane uzamčený u dodavatele. Zrcadlo funguje oběma směry a průběžně se aktualizuje. Není to tedy záloha ani export na vyžádání, ale trvale připravená cesta k odchodu, kterou zákazník zvládne sám.

Bailey provozuje procesy na serveru zákazníka, včetně frontendů, backendů, databází a certifikátů. Aby to bylo pohodlí, a ne závislost, otevře admin Advanced → Settings (jen pro adminy) a použije kartu Git remote. Každý pracovní prostor si vygeneruje vlastní SSH klíč pro nasazení (deploy key). Ten se zobrazí celý s tlačítkem Copy public key a přidá se jako deploy key s právem čtení i zápisu na GitHubu, GitLabu nebo Forgejo. Admin pak vloží zpět SSH adresu repozitáře (git@host:org/repo.git). HTTPS Bailey odmítne, protože ověření zajišťuje právě klíč. Klíč lze na stejné kartě vyměnit (Retire key and generate a new one) a karta eviduje, kdo ho vyměnil a kdy.

Zrcadlo je jeden repozitář s uspořádáním, kterému porozumíte i bez dokumentace Bailey. Větev main obsahuje jednu složku pro každý proces. V každé je kód procesu přesně tak, jak ho má vlastní main daného procesu, a k tomu vygenerovaný README.md, který uspořádání vysvětluje. Větev gitops obsahuje manifesty nasazení, tedy záznam o tom, jaká verze běží v kterém prostředí. Větve copies/<name> zrcadlí každou osobní kopii a každý experiment. Jsou jen pro čtení, při každém odeslání se přepíšou a se smazáním kopie zmizí. Historie nasazení je uložená v tazích deploy/<process>/<timestamp>.

Zrcadlo funguje oběma směry. Než záložka Deploy ukáže stav, Bailey stáhne main ze vzdáleného repozitáře, sloučí nové commity do vlastního main daného procesu a oznámí to: „New changes from the git remote were pulled into main. Sync your copy before deploying.“ Kolega bez přístupu do Bailey tak může poslat opravu do vzdáleného repozitáře a ta se stane součástí příštího nasazení. Bailey sám od sebe nikdy nepřepíše main vynuceným pushem. Pokud main ve vzdáleném repozitáři už není přímým pokračováním (fast-forward) toho, co Bailey odeslal, nebo pokud příchozí změna koliduje s prací v pracovním prostoru, zrcadlení main se zastaví a karta Git remote i záložka Deploy vyjmenují dotčené procesy. Admin pak zvolí Force push to repair (vzdálený repozitář se srovná s pracovním prostorem a Bailey vypíše, co se tím zahodí), nebo Pause the remote (do obnovení se nic neodesílá ani nestahuje). Členové týmu uvidí stejnou lištu s pokynem, ať se obrátí na admina. Procesy v obou případech dál běží na vlastním serveru zákazníka.

Klíčová fakta

• Zrcadlení nastavují jen admini, na kartě Git remote v Advanced → Settings.
• Každý pracovní prostor si vygeneruje vlastní SSH deploy key, který je třeba přidat jako deploy key s právem čtení i zápisu na GitHubu, GitLabu nebo Forgejo.
• Bailey přijme jen SSH adresy (git@host:org/repo.git), HTTPS odmítne.
• Deploy key lze na kartě vyměnit a karta eviduje, kdo ho vyměnil a kdy.
• main obsahuje jednu složku pro každý proces a vygenerovaný README.md, gitops obsahuje manifesty nasazení.
• Větve copies/<name> zrcadlí osobní kopie jen pro čtení a zmizí spolu s kopií. Nasazení mají tagy deploy/<process>/<timestamp>.
• Commity poslané do main ve vzdáleném repozitáři se před dalším nasazením sloučí do Bailey.
• Bailey sám od sebe nikdy neprovede vynucený push do main. Při rozcházení historie nebo konfliktu se zrcadlení main zastaví a dotčené procesy se vyjmenují.
• Jak se z rozcházení historie dostat, rozhoduje admin: Force push to repair, nebo Pause the remote.
• Push status vypíše každou větev a to, co se dostalo do vzdáleného repozitáře.

Jak se používá

1. Otevřete Advanced → Settings (jen pro adminy) a najděte kartu Git remote.
2. Stiskněte Copy public key a přidejte klíč jako deploy key s právem čtení i zápisu do repozitáře na GitHubu, GitLabu nebo Forgejo, který patří vaší organizaci.
3. Vložte SSH adresu repozitáře (git@host:org/repo.git) a uložte ji. HTTPS se nepřijímá.
4. Stiskněte Push now. Push status pak vypíše každou větev a to, co se dostalo do vzdáleného repozitáře.
5. Repozitář si můžete kdykoli naklonovat: main pro kód, gitops pro manifesty, copies/* pro rozpracovanou práci.
6. Pošlete do něj commit zvenčí a ten se před dalším nasazením přes Deploy stáhne do main. Synchronizujte kopii a nasaďte ji.
7. Pokud se main někdy rozejde, rozhodněte vědomě: Force push to repair, nebo Pause the remote, dokud nepadne rozhodnutí.

Proč na tom záleží: Odchod, který vyžaduje požadavek na podporu, není skutečná možnost odejít. Zrcadlo Bailey drží kód, specifikace, výjimky z CVE a záznam o nasazeních v repozitáři, který už zákazník má pod kontrolou, v uspořádání srozumitelném i cizímu člověku a aktualizovaném při každém nasazení. Odchod je tak rozhodnutí, které zákazník udělá bez součinnosti dodavatele. Zákazník nikdy nemusí odejít, a to je něco jiného, než když odejít nemůže.

Mapování na předpisy a normy

• DORA čl. 28 odst. 8 — Strategie ukončení smluvních ujednání s třetími stranami poskytujícími služby IKT: pracovní prostor se sám zrcadlí (kód, manifesty nasazení a historie) do gitového repozitáře, který má pod kontrolou finanční subjekt, takže odchod nevyžaduje žádnou součinnost poskytovatele.
• ISO/IEC 27001 A.5.23 — Bezpečnost informací při využívání cloudových služeb: vše, co služba uchovává, je průběžně k dispozici v repozitáři zákazníka, ve zdokumentovaném uspořádání, a pokrývá celý životní cyklus od pořízení po ukončení.
• ISO/IEC 27001 A.5.30 — Připravenost IKT na kontinuitu činností: aktuální nezávislá kopie každého procesu (kód, specifikace a manifesty) funguje dál, i když platforma, která ji vytvořila, nefunguje.

Mapování opatření na předpisy a normy

Tabulka uvádí všechna opatření z předpisů a norem, která dokumentace platformy Bailey přiřazuje ke konkrétní funkci platformy: 98 mapování napříč NIS2, DORA, ISO/IEC 27001, SOC 2 a GDPR. Každý řádek odkazuje na oddíl, který danou funkci vysvětluje. Mapování ukazuje, jak funkce platformy pomáhají opatření splnit. Nejde o certifikaci.

NIS2, DORA a soulad s předpisy

BitSwan vychází z toho, že opatření, na která se ptají audity podle NIS2 a DORA, jsou vlastnostmi samotného běhového prostředí Bailey. Každá aplikace i automatizace je tak získá ve chvíli, kdy ji nasadíte. BitSwan to shrnuje jako „Automatizace připravená na NIS2 od prvního dne“ a dodává: „Bezpečnostní opatření dodělávaná na poslední chvíli nikoho netěší.“

Podle BitSwan z toho nový zákon o kybernetické bezpečnosti v Česku udělal téma pro vedení firem.

Čtyři otázky auditora a odpovědi, které má Bailey zabudované.

• „Kdo k tomu má přístup?“ Přístup se nastavuje pro každého uživatele i každou automatizaci zvlášť: kdo smí stavět, kdo spouštět a kdo co vidí. Vynucuje ho běhové prostředí, takže auditorovi ukážete obrazovku místo směrnice v PDF.
• „Ukažte mi záznamy.“ Každá akce se zapisuje automaticky. Když se auditor zeptá, odpověď už je v záznamu.
• „Kde jsou data uložená?“ Na serverech zákazníka, v privátním nebo ve veřejném cloudu, podle toho, co si zákazník zvolí. Totéž platí pro to, kde běží AI model. Umístění dat je nastavení nasazení a nikdo o něm nemusí vyjednávat.
• „Dokážete dohledat incident?“ Nasazení mají své verze a dají se vrátit. Spolu s úplnými záznamy ukazují, co se změnilo, kdy a kdo to udělal, a do posledního funkčního stavu se lze vrátit jedním kliknutím.

Opatření podle jednotlivých rámců. Úvodní stránka BitSwan uvádí, že běhové prostředí tato opatření vynucuje u každé aplikace a důkazy samo zapisuje do historie, do které jde jen přidávat:

• NIS2: řízení přístupu, logování i doklady o dodavatelském řetězci obstarává samo běhové prostředí, nestojí to na papírové směrnici.
• DORA: každá změna projde před ostrým provozem zmrazením, testy a podpisem a záznam to doloží.
• ISO/IEC 27001: technická opatření, která chce kontrola podle přílohy A, se vynucují a o každém vynucení vzniká záznam.
• SOC 2: řízení změn a logický přístup doloží historie, kterou nikdo nemůže upravit.
• GDPR: když IT schválí externí server, samy se doplní záznamy o činnostech zpracování podle článku 30 i zpracovatelské smlouvy podle článku 28.

Web BitSwan uvádí, že historie Bailey, do které jde jen přidávat, slouží pro NIS2, DORA, ISO 27001, SOC 2 i GDPR. Popisuje je jako opatření, která platforma vynucuje, a důkazy, které zaznamenává. Netvrdí, že by BitSwan měl certifikaci podle kteréhokoli z těchto rámců.

Stínová AI jako mezera při auditu. Podle BitSwan stejná opatření zavírají „největší mezeru při auditu, o které většina firem ani neví“: stínovou AI. Podle NIS2 je každá vlastnost neřízeného AI prototypu (žádné řízení přístupu, žádné záznamy, žádná izolace, běh na notebooku) potenciálním nálezem auditu.

Rozsah tvrzení BitSwan o souladu s předpisy. Stránka BitSwan o NIS2 uvádí, že popisuje opatření platformy, nejde o právní poradenství a konkrétní povinnosti firmy závisí na tom, jak je firma zařazena. BitSwan nabízí, že při ukázce projde kontrolní seznam zákazníka bod po bodu přímo na běžící platformě, „auditorovi pak věci rovnou předvedete, místo abyste je jen slibovali“.

BitSwan ve srovnání s no-code nástroji a vývojem na zakázku

BitSwan se představuje jako třetí cesta mezi no-code nástroji a vývojem softwaru na zakázku: „Ani no-code, ani vývojový projekt.“ Srovnávací stránka BitSwan říká, že každý přístup se hodí na jinou práci a že BitSwan je stavěný pro procesy, které se dotýkají ERP, banky, mezd nebo auditora.

Kdy BitSwan doporučuje něco jiného. Srovnávací stránka BitSwan radí takto:

• Pokud firma potřebuje jen propojit dva SaaS nástroje, třeba poslat formulář do tabulky nebo upozornit ve Slacku na nového zájemce, má si koupit no-code nástroj. „Do oběda vám to poběží.“
• Pokud je proces produktem firmy a firma kolem něj staví celý tým, může být správnou volbou vývoj na zakázku. Musí ale vybrat dobré lidi a počítat s rozpočtem i na roky po spuštění.
• Pokud se proces dotýká ERP, banky, mezd nebo auditora a patří do „administrativou zavaleného středu skutečné firmy“, je to přesně ta práce, pro kterou dílna BitSwan vznikla. BitSwan k tomu odkazuje na svých patnáct případových studií z ostrého provozu.

Je BitSwan no-code nástroj? Není. Podle BitSwan se v no-code nástrojích skládají kroky v cloudu dodavatele, a jakmile se proces zkomplikuje, narazí se na strop. BitSwan je Dílna pro AI aplikace: člověk běžnou řečí popíše, co potřebuje, AI programovací agent napíše skutečný software (backend, frontend i databázi) a ten pak běží pod kontrolou na infrastruktuře zákazníka, bez stropu, na který by se při skládání narazilo.

Přechod ze Zapieru nebo n8n. Podle BitSwan je přechod ze Zapieru nebo n8n možný a první den většinou nevyžaduje nic odstraňovat. BitSwan se napojí na systémy, které firma už používá. Obvykle se nejdřív pod kontrolou znovu postaví procesy, na kterých firma nejvíc stojí nebo které nejvíc hlídá regulace, a jednoduchá propojení zůstanou, kde jsou, dokud se jejich přesun nebude hodit.

Případové studie

BitSwan zveřejňuje 15 případových studií automatizací, které běží v ostrém provozu. Pokrývají finance, controlling, mzdy, účetnictví, investice, rizika, provoz, obchod a marketing. Všechny na platformě BitSwan postavil implementační partner Harmonum. Každá běží v Bailey, prostředí s řízeným přístupem a auditní stopou, které je stavěné pro NIS2. Právě proto podle BitSwanu „IT každou z nich schválilo“. Případové studie nejmenují klientské firmy a každý citát je podepsaný „Z ostrého provozu“.

Detekce anomálií

Automatizace BitSwanu pro detekci anomálií hlídá živý tok síťových dat telekomunikačního operátora. Každou sekundu vyhodnotí miliony událostí a poruchu označí dřív, než zákazník zavolá.

Oblast: Telekomunikace, provoz.

Výchozí stav: Technici podpory hledali příčinu poruchy ručně v mnoha různých systémech. Diagnostika trvala desítky minut a zákazník celou dobu čekal na lince.

Co automatizace dělá: Je napojená na živý tok technických dat ze sítě. Každou sekundu vyhodnotí miliony událostí a anomálii označí už ve chvíli, kdy vzniká. Diagnostikou pak operátory provede AI asistent.

Výsledek: Diagnostika poruchy trvá sekundy místo minut. Problém zákazníka je jasný okamžitě. Zákazníci jsou spokojenější.

Citát: „Dřív jsme hledali naslepo. Teď poruchu vidíme dřív než zákazník.“

Zdroj: Detekce anomálií

Automatizace faktur a plateb

Automatizace faktur a plateb od BitSwanu zvládne celou cestu od došlé faktury až po odeslanou bankovní platbu a každý krok zapíše.

Oblast: Finance.

Výchozí stav: Došlé faktury se zpracovávaly ručně. Nejdřív se u každé kontrolovalo, jestli se má platit, a pak se hromadně zaplatily přes banku. Data přitom ležela na třech místech: v cloudových složkách, ve fakturačním systému a v internetovém bankovnictví. Vznikaly chyby a měsíční uzávěrka se zdržovala.

Co automatizace dělá: Všechna tři místa propojuje jediná automatizace. Hlídá ve složkách nové faktury, AI agent z nich vytěží data, z dat vzniknou platební soubory v XML a odejdou přes API banky. Ručně se nedělá nic a kontrolu i schválení člověkem lze zařadit do kterékoli fáze.

Výsledek: Celý cyklus od přijetí faktury po úhradu běží automaticky. Chyby z ručního přepisování zmizely. Tým vidí stav faktur a plateb průběžně a každý měsíc mu odpadnou hodiny rutinní práce.

Citát: „Dřív jsme faktury lovili po složkách. Dneska se zaplatí samy.“

Zdroj: Automatizace faktur a plateb

Sklad v reálném čase

Automatizace BitSwanu pro reporting skladu v reálném čase dává velké e-commerce firmě živé dashboardy výkonu a kapacity skladu. Nahradila reporty skládané ze včerejšího exportu.

Oblast: Provoz, e-commerce.

Výchozí stav: Reporting skladu se skládal ručně v Excelu z exportů z WMS. Čísla proto přicházela vždycky pozdě a pokaždé stála ruční práci.

Co automatizace dělá: Čte živý tok dat ze všech firemních systémů, tedy o skladnících, vychystávačích, docházce i objednávkách, a průběžně z nich skládá živé dashboardy výkonu a vytížení kapacit.

Výsledek: Provoz skladu je vidět v reálném čase. Ruční exporty i chyby v nich odpadly. Na přetížení se reaguje hned, jak vzniká.

Citát: „Dřív jsme hvězdy pozorovali pouhým okem. Teď máme dalekohled.“

Zdroj: Sklad v reálném čase

Stahování bankovních výpisů

Automatizace BitSwanu pro stahování bankovních výpisů podle plánu stahuje výpisy pro víc než padesát klientských účtů účetní kanceláře. Dává jim jednotné názvy a ukládá je tam, kde je účetní proces čeká, ještě než účetní začnou pracovat.

Oblast: Finance, účetnictví.

Výchozí stav: Ráno v účetní kanceláři začínalo pokaždé přihlašováním do internetového bankovnictví u víc než padesáti klientských účtů, banku po bance: dvoufázové ověření, najít výpis, exportovat, přejmenovat, uložit. Než mohla začít skutečná práce, uběhlo několik hodin klikání. Stačilo jedno vynechané ráno a odsouhlasení se zpozdilo u všech klientů, kteří byli na řadě potom.

Co automatizace dělá: Běží ještě před začátkem pracovní doby. Připojí se ke každé bance, stáhne všechny nové výpisy, sjednotí formáty tam, kde se banky liší, a každý výpis pojmenuje a uloží přesně tam, kde ho účetní proces čeká. Když něco selže, třeba vyprší přihlašovací údaje nebo banka změní rozhraní, upozorní na to člověka a nic potichu nepřeskočí. Přihlašovací údaje k bankám jsou uložené ve správci tajných údajů, nikdy v tabulce, a každý běh se zapisuje do Bailey kanceláře.

Výsledek: Ranní rutina zabere místo hodin pár minut. Výpisy jsou každý den uložené a jednotně pojmenované. Odsouhlasení začíná hned se začátkem práce. Přístupy k bankám jsou ve správci tajných údajů a každé stažení se zapisuje.

Citát: „Do bankovnictví už neklikám. Výpisy mám ráno nachystané.“

Zdroj: Stahování bankovních výpisů

Automatizace faktur

Automatizace faktur od BitSwanu připravuje měsíční fakturaci pro stovky klientů mezinárodní účetní firmy, aniž by kvůli tomu manažer otevřel tabulku.

Oblast: Finance, služby.

Výchozí stav: Podklady k fakturaci skládali manažeři ručně. Ke každé odvedené práci dohledávali, kdo ji udělal a jakou sazbu na ni má klient ve smlouvě. Byla to náročná práce a chyby se v ní dělaly snadno.

Co automatizace dělá: Spolupracují dvě automatizace. První načte parametry smluv, tedy druhy práce, sazby a ceníky, do jedné referenční tabulky. Druhá je napojená na systém, ve kterém se vykazuje odvedená práce, a každému klientovi sama vystaví fakturu.

Výsledek: Příprava podkladů k fakturaci běží celá automaticky, s výraznou úsporou času a bez chyb. U každé fakturované částky je jasně vidět, za jakou odvedenou práci se účtuje.

Citát: „Manažeři teď tráví měsíc s klienty místo s tabulkami.“

Zdroj: Automatizace faktur

Docházka a mzdy

Automatizace BitSwanu pro docházku a mzdy sjednotí a zkontroluje měsíční docházku, kterou personální agentura dostává od každého klienta v jiném formátu. Příprava mezd tak zabere místo dnů minuty.

Oblast: Mzdy.

Výchozí stav: Personální agentura dostávala každý měsíc docházku od všech klientů a každý ji posílal jinak, jeden v PDF, druhý v Excelu. Mzdové účetní ji ručně přepisovaly do jednoho modelu. Každý měsíc to byly dny náročné práce, při které se snadno udělala chyba.

Co automatizace dělá: Načte PDF i excelové soubory, převede je do jednotného formátu, zkontroluje vstupy a připraví soubory pro import do mzdového systému. V celém řetězci už nikdo nic nepřepisuje.

Výsledek: Příprava podkladů pro mzdy trvá minuty místo dnů. Chyby z ručního přepisování odpadly. Správnost dat se kontroluje v několika krocích.

Citát: „Celé dny jsme přepisovali tabulky. Teď se zpracují samy.“

Zdroj: Docházka a mzdy

Zaměstnanecké odměny ve mzdách

Automatizace BitSwanu pro odměny ve mzdách spočítá odměny, které zaměstnanci dostávají za nákupy ve firemním maloobchodním řetězci, a výslednou mzdu najednou nahraje do mzdového systému.

Oblast: Mzdy.

Výchozí stav: Zaměstnanci dostávají odměnu, když nakoupí zlevněné zboží ve firemním maloobchodním řetězci, a ta se musí správně promítnout do mzdy i do úředních výkazů. Účetní ručně procházeli zdrojová data z každé prodejny a přepisovali hodnoty nákupů. Trvalo to dlouho a chyby se nedaly vyloučit.

Co automatizace dělá: Jeden automatizovaný systém vezme tabulku nákupů a tabulku základních mezd, jedním algoritmem spočítá výslednou mzdu každého zaměstnance a výsledek nahraje rovnou do mzdového systému. BitSwan ho popisuje jako auditovaný krok mzdového cyklu, který se řídí stejnými pravidly a nic se v něm nepřepisuje.

Výsledek: Výpočet mezd trvá minuty místo několika dnů. Data se kontrolují automaticky a výpočty vycházejí pokaždé stejně. Účetní tým má zase čas na jinou práci a ruční zpracování přináší méně chyb.

Citát: „Místo tabulek plných čísel stačí jedno kliknutí a mzdy jsou hotové.“

Zdroj: Zaměstnanecké odměny ve mzdách

Zaúčtování účtenek

Automatizace BitSwanu pro zaúčtování účtenek nechá fotky a PDF účtenek přečíst AI agenta, zařadí je podle účtové osnovy firmy a zaúčtuje do účetního systému. Člověk je kontroluje tam, kde to firma chce.

Oblast: Účetnictví.

Výchozí stav: Účtenky chodily z celé firmy ve všech možných podobách: fotky z mobilu, PDF v e-mailu, zmačkané skeny. Dodavatele, datum, částku a DPH do účetnictví někdo ručně přepisoval a zařazení záviselo na tom, kdo ten den zrovna seděl u klávesnice. Měsíční uzávěrka čekala, až se probere „krabice papírků“.

Co automatizace dělá: Hlídá vstupy, tedy e-mailovou schránku a složku. AI agent každou účtenku přečte a vytáhne z ní dodavatele, datum, částku a sazbu DPH. Kategorii určí podle účtové osnovy a dřívějších zaúčtování. Jasné položky jdou rovnou do účetního systému, a kde si agent jistý není, pošle účtenku účetní ke schválení jedním kliknutím. Každý krok běží ve firemním Bailey, je zapsaný a dohledatelný a přístup k němu je řízený.

Výsledek: Účtenky se účtují bez přepisování. Zařazení je jednotné, protože rozhoduje účtová osnova, ne ten, kdo zrovna píše. Měsíční uzávěrka už nečeká na papíry. Každé zaúčtování se dá dohledat až k původní účtence.

Citát: „Krabice s účtenkami se teď vyprazdňuje sama.“

Zdroj: Zaúčtování účtenek

Kontrola faktur za elektřinu

Automatizace BitSwanu pro kontrolu faktur za elektřinu automaticky porovnává vyúčtovanou a skutečnou spotřebu elektřiny u tisíců odběrných míst základnových stanic mobilního operátora.

Oblast: Controlling, telekomunikace.

Výchozí stav: Finanční oddělení mělo kontrolovat faktury za elektřinu pro základnové stanice operátora. Šlo o tisíce odběrných míst a několik dodavatelů a v praxi se nedalo ověřit, jestli vyúčtování odpovídá skutečné spotřebě. Neoprávněných odběrů ani poruch si nikdo nevšiml.

Co automatizace dělá: Spolupracují tři automatizace, které na sebe navazují. První čte faktury v PDF a u každé stanice z nich vytáhne vyúčtovanou spotřebu. Druhá měří, kolik zařízení skutečně odebírají. Třetí obě čísla porovná a upozorní na anomálie. Podle BitSwanu se přeúčtování odhalí v den, kdy faktura dorazí, a ne až na konci roku.

Výsledek: Tisíce odběrných míst se kontrolují automaticky. Odchylky a anomálie ve spotřebě jsou hned vidět. Firma má okamžitý přehled o nákladech na energie.

Citát: „Poprvé máme přehled o spotřebě celé sítě, a to bez ruční práce.“

Zdroj: Kontrola faktur za elektřinu

Párování faktur s výsledovkou

Automatizace BitSwanu pro párování faktur s výsledovkou nechá AI agenta přečíst faktury z patnácti evropských zemí v jakémkoli jazyce a formátu a sloučí je do jedné tabulky, ze které se počítá výsledovka.

Oblast: Controlling, audit.

Výchozí stav: Auditorská firma kontroluje výsledovku proti přijatým fakturám z patnácti evropských zemí. Faktury posílá několik partnerů v mnoha formátech a jazycích. Přepsat je do excelových modelů trvalo dny a u přepsaného čísla se nedalo dohledat, odkud se vzalo. Když něco nesedělo, hledání zdrojové faktury byla „detektivka“.

Co automatizace dělá: Pracují dvě automatizace, které na sebe navazují. První faktury stáhne a AI agent každou z nich přečte bez ohledu na jazyk a formát a obsah zapíše do strukturovaných tabulek. Druhá všechny formáty sloučí do jedné jednotné tabulky, ze které se počítá výsledovka. Každé číslo si nese odkaz na svou zdrojovou fakturu a každý běh se zapisuje, takže se párování dá auditovat od začátku do konce.

Výsledek: Místo dnů přepisování stačí minuty. Patnáct zemí, řada jazyků a formátů dnes plní jednu tabulku. Každé číslo ve výsledovce se dá dohledat až ke zdrojové faktuře. Nesrovnalosti najde systém, při přepisování už nezapadnou.

Citát: „Faktury z patnácti zemí máme konečně v jedné čisté tabulce.“

Zdroj: Párování faktur s výsledovkou

Výpočet NAV fondů

Automatizace BitSwanu pro výpočet NAV oceňuje stovky spravovaných fondů během několika minut, takže velikost finančního týmu už neomezuje, kolik fondů může firma spravovat.

Oblast: Investice.

Výchozí stav: Finanční oddělení každý měsíc počítalo hodnotu podílových listů pro stovky spravovaných fondů. Vstupní data ručně kopírovalo z firemního systému do složitých excelových modelů, pro každý fond zvlášť. Šlo to pomalu, chyba se vloudila snadno a celý proces byl tvrdým stropem, přes který firma nemohla dál růst.

Co automatizace dělá: Excelové modely byly přepsané do kódu v Pythonu. Systém pro řízení workflow zavolá automatizaci s parametry každého fondu a hodnotu podílového listu dostane zpátky rovnou do interního systému. Podle BitSwanu se ocenění počítá podle plánu přímo ze zdrojových dat a s úplnou auditní stopou.

Výsledek: Výpočet trvá minuty místo hodin. Ruční kopírování odpadlo a s ním i chyby. Fondů může přibývat, aniž by musel růst tým.

Citát: „Na čem analytici dřív seděli hodiny, to má systém hotové za pár minut.“

Zdroj: Výpočet NAV fondů

Poplatky za odkupy

Automatizace BitSwanu pro poplatky za odkupy odvodí vzorce výstupních poplatků z podepsaných klientských smluv a poplatek za odkup spočítá za několik sekund.

Oblast: Investice.

Výchozí stav: Když klient prodává aktivum, back office musí spočítat výstupní poplatek podle parametrů podepsané smlouvy. Ručně to šlo pomalu, snadno se udělala chyba a obchodní oddělení mezitím čekalo.

Co automatizace dělá: Spolupracují dvě automatizace. V první AI agent prošel všechny smlouvy a odvodil z nich vzorce pro poplatky. Druhá tyto vzorce použije pokaždé, když je výpočet potřeba.

Výsledek: Výpočet poplatku trvá sekundy místo hodin. Nikdo už ručně nehledá ve smlouvách. Výpočty jsou jednotné a auditovatelné napříč všemi fondy.

Citát: „Dřív smlouva a kalkulačka, dneska jedno kliknutí.“

Zdroj: Poplatky za odkupy

Hlídání insolvencí v celé EU

Automatizace BitSwanu pro hlídání insolvencí v EU sbírá záznamy z národních insolvenčních rejstříků po celé EU, překládá je a pro advokátní kanceláře je slučuje do jednoho systému v angličtině.

Oblast: Právo, rizika.

Výchozí stav: Advokátní kanceláře musí hlídat insolvenční rejstříky po celé Evropě, aby včas zachytily klienty, kteří míří do úpadku. Každý stát ale vede rejstřík ve svém jazyce a formátu, takže se v nich mezinárodní kancelář skoro nemá šanci vyznat.

Co automatizace dělá: Samostatná aplikace podle plánu sbírá insolvenční záznamy z celé EU a řada navazujících automatizací je přeloží, roztřídí a sloučí do jednoho systému v angličtině.

Výsledek: Národní rejstříky se slučují a překládají automaticky. Insolvence z celé EU se dají sledovat v angličtině. Ušetří se stovky hodin právní analýzy.

Citát: „Dřív jsme se dny prohrabovali rejstříky, dnes máme všechno v jednom přehledu.“

Zdroj: Hlídání insolvencí v celé EU

Hlídání cen konkurence

Automatizace BitSwanu pro hlídání cen konkurence podle plánu stahuje a zpracovává ceníky konkurence z webu, takže obchodní tým může konkurenci sledovat kterýkoli den, a ne jen jednou za měsíc.

Oblast: Obchod.

Výchozí stav: Obchodní tým každý měsíc ručně dohledával ceny konkurence a přepisoval je do srovnávací tabulky. Zabralo to dny náročné práce a právě z téhle tabulky firma vycházela, když stanovovala vlastní ceny.

Co automatizace dělá: Podle plánu stahuje ceníky konkurence z webu, vytáhne z nich data, převede je do potřebné podoby a předá je modelu v Pythonu, který nahradil dřívější tabulkový model v Excelu. Změny pošle lidem, kteří nastavují ceny firmy.

Výsledek: Zpracování trvá minuty místo dnů. Chyby z ručního přepisování odpadly. Konkurenci lze sledovat kterýkoli den, a ne jednou za měsíc.

Citát: „Porovnávání ceníků nám dřív zabralo týdny, teď je to pár minut.“

Zdroj: Hlídání cen konkurence

Schvalování PR textů

Automatizace BitSwanu pro schvalování PR textů nahrazuje schvalování přes dokumenty ve Wordu a e-maily jedním sledovaným procesem, ve kterém je text, schvalovatelé i finální souhlas.

Oblast: Marketing, investice.

Výchozí stav: PR tým psal texty a souhlas klientů naháněl přes dokumenty ve Wordu a e-mailová vlákna. Verze se pletly, schvalování se zasekávalo a tým nestíhal klienty, kteří své požadavky rychle měnili.

Co automatizace dělá: Dává týmu rozhraní, ve kterém stačí napsat text, připojit seznam schvalovatelů a odeslat. Doručení e-mailem proběhne automaticky, každý krok se zapisuje a proces hlídá, aby schvalování nikde neuvízlo. Záznam ukazuje, kdo co schválil a kdy.

Výsledek: Schvalování trvá hodiny místo dnů. Vždy je jasné, která verze platí a kdo už schválil. S klienty se pracuje rychleji a v klidu.

Citát: „Konečně systém, který s námi drží krok.“

Zdroj: Schvalování PR textů

Zákazníci a výsledky

BitSwan uvádí, že je v ostrém provozu víc než pět let a že na něm více než 10 firemních klientů provozuje přes 50 aktivních automatizací. Mezi zákazníky jsou firmy z telekomunikací, právních služeb, investičních fondů, výroby, automobilového průmyslu, e-commerce a finančních služeb.

Čísla, která uvádí bitswan.ai.

• V ostrém provozu: 5+ let.
• Firemní klienti: 10+.
• Aktivní automatizace: 50+.
• Zveřejněné případové studie: 15, všechny v ostrém provozu.

Jmenovaní zákazníci. Úvodní stránka BitSwanu uvádí tyto zákazníky a jejich obory:

Citát zákazníka. Úvodní stránka BitSwanu zveřejňuje toto vyjádření:

„Dřív jsme měli roztroušené skripty a spoustu ručního kopírování. Dnes nám hlavní telekomunikační a finanční procesy běží na jedné řízené platformě. S BitSwanem jsme pružní a bezpečnostní audity tím přitom nijak netrpí.“ Juraj Eliáš · Chief Core Network Architect, CETIN Group

Případové studie. Patnáct zveřejněných případových studií BitSwanu popisuje automatizace v ostrém provozu, ale klienta nejmenuje. Mezi popsanými klienty jsou telekomunikační operátor, mobilní operátor s tisíci odběrných míst základnových stanic, velká e-commerce firma, účetní kancelář s víc než padesáti bankovními účty klientů, mezinárodní účetní firma, která fakturuje stovkám klientů, personální agentura, auditorská firma působící v patnácti evropských zemích, správce stovek fondů a advokátní kanceláře, které hlídají insolvenční rejstříky v EU. Všech 15 postavil na platformě BitSwan Harmonum. Stránka týmu BitSwanu uvádí, že „každá případová studie na tomto webu má konkrétní tvář“.

Tým

Tým BitSwanu a tým Harmonum tvoří titíž lidé. BitSwan to říká takto: „Jsme jeden tým v jedné dílně. Lidé, kteří vyvíjejí BitSwan, vedou i Harmonum, našeho implementačního partnera. Proto má každá případová studie na tomto webu konkrétní tvář.“ Generálním ředitelem (CEO) firmy je Tomáš Doležal a technickým ředitelem (CTO) Timothy Hobbs.

Stránka týmu BitSwanu uvádí 17 lidí a dodává, že tým je větší: „Je nás víc, než se sem vejde. Ostatní ještě čekají na focení.“

Program nezávislých poradců pro automatizaci

V programu nezávislých poradců pro automatizaci si jednotliví poradci založí v Bailey veřejný profil a systém je propojí s firmami, které chtějí automatizovat své procesy. Zakázky tak získávají jako součást ekosystému BitSwan.

• Veřejný profil: navždy zdarma.
• Školení: k profilu patří bezplatné školení v AI poradenství.
• Přihlášení: zájemci se zapíšou na čekací listinu na stránce pro poradce a e-mailovou adresu potvrdí odkazem, který jim přijde do schránky. Na seznamu je udrží právě toto potvrzení.
• Pomoc s profilem: kdo chce pomoct s nastavením veřejného profilu, může poslat životopis na support@bitswan.ai.

Zdroj: Staňte se nezávislým poradcem pro automatizaci

Časté otázky

Co je BitSwan?

BitSwan je Dílna pro AI aplikace. Lidé z firmy popíší proces vlastními slovy, AI programovací agent, například Claude Code, pro něj napíše skutečný software a výsledek pak běží pod kontrolou v soukromém běhovém prostředí jménem Bailey. BitSwan si klade za cíl proměnit stínovou AI v bezpečné inovace uvnitř firmy.

Dostane se programovací agent v BitSwan do ostrého provozu?

Ne. Vývojové, testovací i produkční prostředí má v Bailey každé svou databázi, úložiště souborů a síť a programovací agent pracuje jen ve vývojovém. Do ostrého provozu se dostane jedině verze, kterou auditor zmrazil, prošel a podepsal.

Co opouští naši síť, když používáme BitSwan?

Jen provoz na servery, které schválilo IT. V testovacím i produkčním prostředí Bailey je odchozí provoz ve výchozím stavu zakázaný a každé schválení se zapíše. AI model může běžet i v infrastruktuře zákazníka, takže ven nemusejí ani prompty.

Kdo v BitSwan schvaluje nasazení?

Každé nasazení v Bailey schvaluje auditor, kterého určí zákazník a který aplikaci sám nestavěl. Auditor zmrazí přesnou verzi, projde změny v kódu a podepíše je. Tímto podpisem se verze zároveň povýší do ostrého provozu.

Funguje BitSwan s Claude Code, který už naši vývojáři používají?

Ano. Claude Code, Codex, Cursor i další agenti z terminálu běží v dílně BitSwan beze změny. Rozdíl je v tom, že výsledek neskončí na něčím notebooku, ale v prověřeném běhovém prostředí Bailey, kde se všechno zaznamenává.

Co všechno zachytí auditní stopa v BitSwan?

Auditní stopa v Bailey zachytí každé sestavení, žádost o odchozí spojení, schválení, podpis a nasazení, vždy i s tím, kdo a kdy to udělal. Do záznamu jde jen přidávat, takže ho nepřepíše ani provozovatel, a pro auditory se dá vyexportovat.

Co se stane s aplikacemi, když s BitSwanem skončíme?

Poběží dál. BitSwan staví skutečný kód v repozitáři zákazníka a na jeho infrastruktuře, takže uvnitř produktu, který by zákazník musel opustit, nezůstane nic.

Je BitSwan no-code nástroj?

Ne. No-code nástroje skládají hotové kroky v cloudu dodavatele a u složitějších procesů narazí na strop. V BitSwan píše AI programovací agent skutečný software (backend, frontend i databázi), který běží pod kontrolou na infrastruktuře zákazníka a žádný strop nemá.

Můžeme na BitSwan přejít ze Zapieru nebo n8n?

Ano, a první den většinou nemusíte nic vytrhávat. BitSwan se napojí na systémy, které už firma používá. Obvykle se v Bailey nejdřív znovu postaví procesy, na kterých firma nejvíc stojí nebo které nejvíc hlídá regulace, a jednoduchá propojení zůstanou, kde jsou, dokud se jejich přesun nebude hodit.

Co je stínová AI a proč podle BitSwan nepomůže ji zakázat?

BitSwan označuje za stínovou AI jakýkoli AI nástroj nebo software postavený s pomocí AI, který lidé ve firmě používají bez vědomí, souhlasu a kontroly IT. Podle BitSwan zákaz takových nástrojů neodstraní poptávku, jen přehled, protože lidé stavějí dál na soukromých účtech a vlastních zařízeních. Řešením je řízené běhové prostředí jako Bailey, ve kterém je správná cesta zároveň ta nejsnazší.

Kde Bailey od BitSwan běží?

Bailey běží na vlastních serverech zákazníka, v privátním nebo ve veřejném cloudu, podle toho, co si zákazník zvolí. Kde poběží AI model, se nastavuje zvlášť: buď celý na vlastní infrastruktuře, nebo jako model přes API. V obou případech je pod kontrolou a v záznamu, co model vidí.

Jak BitSwan pomáhá s audity podle NIS2 a DORA?

BitSwan má opatření, na která se ptají audity podle NIS2 a DORA, zabudovaná přímo v běhovém prostředí Bailey: řízení přístupu pro každého uživatele i každou automatizaci, automatické zapisování každé akce, nastavení umístění dat při nasazení a verzovaná nasazení, která se dají vrátit a podle kterých se dohledá incident. Kvůli DORA projde každá změna před ostrým provozem zmrazením, testy a podpisem. BitSwan zároveň upozorňuje, že jeho stránka o NIS2 popisuje opatření platformy a není právním poradenstvím.

Podporuje BitSwan doklady pro ISO 27001, SOC 2 a GDPR?

Podle BitSwan Bailey vynucuje technická opatření, která chce kontrola podle přílohy A normy ISO/IEC 27001, a o každém vynucení vede záznam. Historie, kterou nikdo nemůže upravit, pak dokládá řízení změn a logický přístup pro SOC 2. Pro GDPR Bailey průběžně vytváří záznamy o činnostech zpracování podle článku 30 a zpracovatelské smlouvy podle článku 28, jak IT schvaluje externí servery.

Jak rychle dostane BitSwan první automatizaci do ostrého provozu?

Podle BitSwan běží první automatizace v ostrém provozu už první týden. Jeho průvodce stínovou AI uvádí, že první znovu postavený stínový prototyp „může v ostrém provozu běžet do týdne“.

Jaký cenový model má BitSwan?

BitSwan účtuje licenci na platformu a licenci za každou automatizaci. Než se nasadí ve větším, ukáže přínos nejdřív pilot. Ceny BitSwan na svém webu nezveřejňuje.

Kdo se stará o automatizace postavené v BitSwan?

BitSwan má pohotovostní tým 24/7, který zasáhne, když se některý z napojených systémů změní. Srovnává to s no-code nástroji, kde si automatizace udržuje zákazník sám v mezích, které mu nástroj dovolí, a s vývojem na zakázku, jehož údržbu platí zákazník ze svého rozpočtu bez konce.

Které firmy BitSwan používají?

Na úvodní stránce BitSwan uvádí CETIN (telekomunikace), KŠD (právní služby), AVANT (investiční fondy), VAFO (výroba), Emil Frey (automobilový průmysl), Famico (e-commerce) a Process Solution (finanční služby). BitSwan uvádí více než 10 firemních klientů, více než 50 aktivních automatizací a více než pět let v ostrém provozu.

Jaké procesy BitSwan automatizuje?

BitSwan se zaměřuje na střed firmy, kde je nejvíc administrativy: finance, controlling, mzdy, účetnictví, investice, rizika, provoz, obchod a marketing. Mezi jeho 15 zveřejněnými případovými studiemi jsou například automatizace faktur a plateb, stahování bankovních výpisů, výpočet NAV fondů, hlídání insolvencí v celé EU a detekce anomálií v síti v reálném čase.

Kdo je Harmonum a jaký má vztah k BitSwan?

Harmonum je implementační partner BitSwan se sídlem v Praze a postavil všech 15 automatizací ze zveřejněných případových studií BitSwan. BitSwan vyvíjejí a Harmonum vedou titíž lidé, slovy BitSwan: „Jsme jeden tým v jedné dílně.“

Jak si domluvit demo BitSwan?

BitSwan nabízí 30minutové demo v češtině nebo angličtině, na kterém ukáže Bailey a skutečné automatizace v provozu, bez prezentací a bez závazků. Zájemce si ho domluví tlačítkem „Domluvit 30minutové demo“ na bitswan.ai a BitSwan mu zavolá kvůli termínu. Obchodní oddělení je k zastižení také na sales@harmonum.ai.

Co se v Bailey stane, když útočník získá heslo nebo SSO účet zaměstnance?

Bailey neváže přístup jen na identitu, ale i na schválená zařízení. Ukradené heslo, a dokonce ani zcela kompromitovaný účet u poskytovatele identit nebo v SSO, se proto samo o sobě do Bailey ani k firemním procesům za ním nedostane. Nové zařízení musí zobrazit šestimístný kód a schválit ho je třeba ze zařízení, které už je důvěryhodné.

Jak získá nový notebook nebo prohlížeč přístup do Bailey?

Nový prohlížeč zobrazí šestimístný kód a čeká. Uživatel s už důvěryhodným zařízením zadá tento kód v Your devices → Link a device (Vaše zařízení → Propojit zařízení) a nový prohlížeč se tím stane důvěryhodným zařízením.

Co dělat v Bailey, když se ztratí nebo je ukraden notebook?

Odeberte zařízení na stránce Your devices. Tím se okamžitě zneplatní jeho cookie v celé konzoli Bailey i ve všech aplikacích pracovního prostoru. Samotná změna hesla naopak neukončí relaci, která už je otevřená na ukradeném, odemčeném notebooku.

Kdo může v Bailey vytvořit magic link a k čemu opravňuje?

Magic link může vytvořit jen uživatel, který endpoint vlastní a zároveň má roli admin nebo auditor, a to v dialogu Share daného endpointu a jen pro produkční endpointy. Otevření odkazu udělí prohlížeči důvěru pouze pro tento jeden endpoint, nikdy plnou, a nikoho nepřidá na seznam přístupů. O tom, kdo se dostane dovnitř, dál rozhoduje ACL endpointu.

Jak Bailey odděluje data vývojového, testovacího a produkčního prostředí?

Každý firemní proces v Bailey běží ve třech prostředích, Development, Staging a Production (vývojové, testovací a produkční), a každé z nich má vlastní databázi, úložiště souborů a izolovanou síť Dockeru. Prostředí na sebe navzájem nedosáhnou a produkční data se ve vývojovém ani testovacím prostředí nikdy neobjeví.

Může se v Bailey kód dostat do produkce bez kontroly?

Model prostředí v Bailey dělá z povýšení do produkce samostatný, vědomý krok, který se dá zkontrolovat a který je oddělený od stavby a nasazování ve vývojovém a testovacím prostředí. Zkušený kontrolor ho tak může nejdřív podepsat. Do hlavní větve (main) se kód dostane jedině vědomým nasazením přes Deploy z osobní kopie uživatele.

Má AI programovací agent v Bailey přístup k produkčním datům?

Ne. Coding Agent v Bailey pracuje v izolované kopii uživatele. Na internet se dostane, ale k produkční databázi ani k uživatelským datům v ní ne. Jeho odchozí provoz omezuje seznam povolených cílů ve firewallu pracovního prostoru a jeho výstup musí před nasazením projít skenováním CVE a záložkou Deploy.

Jak poznám, které požadavky v Bailey jsou skutečně pokryté testy?

Bailey sleduje stav požadavku (proposed, pending, fail, retest, pass) odděleně od toho, zda k němu existuje test. Záložka Requirements & tests hledá test, který nese ID požadavku. Požadavek může ukazovat pass jen na základě úsudku, proto je potřeba kontrolovat i pokrytí testy, nejen stav.

Můžou si uživatelé v Bailey sami označit požadavek jako splněný?

Ne. V Bailey vzniká pass a fail jedině z běhu testu nebo ze zjištění, které agent zapíše při stavbě. Uživatelé mohou přijmout návrh agenta do zadání, nebo vrátit splněný požadavek k nové kontrole.

Dá se experiment v Bailey nasadit rovnou do produkce?

Ne. Uvnitř experimentu v Bailey se záložka Deploy vůbec nezobrazí a server jakékoli publikování z něj odmítne. Práce může experiment opustit jen tak, že se sloučí do osobní kopie uživatele nebo se jí stane, a z kopie odchází jedině přes Deploy.

Potřebuje aplikace v Bailey vlastní hosting, nastavení DNS nebo TLS certifikát?

Ne. Frontend firemního procesu v Bailey dostane hned po spuštění skutečný, směrovatelný hostname zabezpečený TLS na vlastní doméně serveru Bailey. Backend zůstává mimo veřejný internet a dosáhne na něj jen frontend přes privátní síť pracovního prostoru. Vlastní doména je volitelná.

Jsme se zdrojovým kódem v Bailey uzamčení?

Ne. Admin Bailey může pracovní prostor zrcadlit do git repozitáře, který organizace sama spravuje, takže zdrojový kód může být hostovaný jinde, pokud se tak organizace rozhodne.

Jak auditor zjistí, co Bailey vystavuje a kdo to vlastní?

Stránka Endpoint access v konzoli Bailey vypisuje každý chráněný hostname za přístupovou bránou, včetně dashboardů pracovních prostorů, gitops a frontendů automatizací, vždy s vlastníkem a pracovním prostorem. Seznam se sestavuje z aktuálního stavu. Server overview k tomu přidává počty pracovních prostorů a důvěryhodných zařízení a stav platformy.

Na která opatření z předpisů a norem se mapují funkce Bailey pro přístup a oddělení prostředí?

Příručka Bailey mapuje důvěru zařízení na NIS2 čl. 21 odst. 2 písm. j), SOC 2 CC6.1, ISO/IEC 27001 A.5.15 / A.8.5 a DORA čl. 9 odst. 3 a oddělení prostředí na ISO/IEC 27001 A.8.31, SOC 2 CC8.1 a GDPR čl. 5 odst. 1 písm. c). Jde o mapování na opatření, nikoli o certifikace.

Může vývojář v Bailey nasazením přepsat změnu, kterou už publikoval kolega?

Ne. Hlavní větev main je v Bailey chráněná a přijímá jen fast-forward, takže když je kopie za main pozadu, nahradí tlačítko Deploy hláška „sync first“ a tlačítko Go to Sync. Jediná alternativa, Deploy this version, overwriting main…, vypíše každý commit, který nahradí, a pro potvrzení je nutné napsat název firemního procesu.

Dělá Bailey někdy force-push nebo přepisuje historii v gitu?

Ne. Každé nasazení posouvá main jen dopředu. I volba přepsání přehraje commity na vrchol main a přidá commit, který soubory viditelně odebere, takže předchozí commity v main zůstanou dosažitelné. Proto je historie nasazení v Bailey už ze své konstrukce taková, že do ní jde jen přidávat.

Kdo může v Bailey povýšit změnu do produkce?

Běžní členové ne. Auditor nebo admin musí testovací prostředí zmrazit a Promote to Production se odemkne až po splnění počtu podpisů auditorů, který vyžaduje politika auditu (aspoň jeden). Jediné Request changes povýšení zablokuje.

Co přesně auditor v Bailey podepisuje?

Auditor podepisuje písemnou zprávu s připravenou osnovou What this version changes, Risk, Verified a Not verified (co verze mění, riziko, ověřeno, neověřeno) a podpis je svázaný s hashem obsahu zmrazeného image. Zpráva i verdikt se commitují do bitswan.yaml v git repozitáři firemního procesu a jsou připsané auditorovi.

Dá se v Bailey změnit schválení, když už je verze vydaná?

Ne. Při povýšení verze do produkce Bailey zapíše, které verdikty ji uvolnily, a daný image už nepřijímá žádné nové podpisy. Nový audit vyžaduje novou verzi s vlastním zmrazením a auditem.

Běží v produkci nově sestavený kód, nebo přesně to, co prošlo testovacím prostředím?

Přesně to, co prošlo testovacím prostředím. Bailey povyšuje image beze změny a znovu nasadí přesně ty bajty, které se sestavily a zkontrolovaly, i když se zdrojový kód mezitím posunul dál.

Jak se Bailey vyhne výpadku při povýšení nebo návratu k předchozí verzi?

Každé povýšení je blue-green přepnutí mezi třemi sloty aplikace nad dvěma trvalými databázemi: nečinný slot se spustí nad živou databází, ingress se přesměruje na něj a starý slot se vyřadí. Návrat do záložního slotu je stejně rychlý.

Jak auditor zjistí, co přesně běželo v dřívějším nasazení v Bailey?

Inspect u kteréhokoli nasazení ukáže Diff vs current (rozdíl proti aktuální verzi), Files (přesný strom zdrojového kódu), Secrets snapshot (sadu tajných údajů, která tehdy platila) a Download image (sestavený image a balíček se schématem). Roll back znovu nasadí přesně tento zaznamenaný image a návrat zapíše jako nový záznam.

Kde Bailey ukládá tajné údaje a kdo je smí měnit?

Tajné údaje jsou hodnoty pro každé prostředí zvlášť, které se vkládají při nasazení a nikdy se necommitují do repozitáře. Členové je mohou číst, zapisovat je smějí jen admini a auditoři a každé nasazení si uloží snímek sady tajných údajů, která v tu chvíli platí.

Jak Bailey testuje obnovu po havárii bez rizika pro produkci?

Bailey obnoví produkční zálohu do izolovaného DR slotu, nikdy přímo do živé produkce. Tam se záloha ověří a označí jako recovery-tested (obnova vyzkoušená). Přechod do ostrého provozu je přepnutí ingressu tlačítkem Restore bez migrace dat, bez nového nasazení a bez výpadku.

Co zahrnují zálohy v Bailey?

Snímky v Bailey zachytí živou blue-green databázi i objektové úložiště a průběh hlásí zvlášť pro každé úložiště (Postgres, CouchDB a Garage). Snímky mají štítek a velikost, dají se obnovit i naklonovat mezi prostředími a řídí se politikou uchovávání.

Jak Bailey pomáhá s článkem 30 a článkem 28 GDPR?

Firewall pro odchozí provoz je v Bailey v testovacím a produkčním prostředí ve výchozím stavu zakázaný a schválení odchozího serveru vyžaduje záznam o zpracování: zda se posílají osobní údaje, jaké údaje, za jakým účelem, jak se ukládají, v jaké jurisdikci a podepsanou zpracovatelskou smlouvu (DPA). Záznamy o činnostech zpracování podle článku 30 a složka zpracovatelských smluv podle článku 28 tak přibývají samy během provozu.

Jak Bailey zaznamenává akceptované zranitelnosti (výjimky z CVE)?

CVE označená jako mimo rozsah se zapíše do cve-waivers.yaml ve stromu zdrojového kódu firemního procesu i s tím, kdo, kdy a proč ji tak označil, a odejde s dalším nasazením přes Deploy. Každá výjimka je uvedená v samostatné části auditní stopy, kde ji kontrolor může zrušit, a jen ke čtení se zobrazuje na produkční záložce Supply chain.

Vytváří Bailey SBOM?

Ano. Každý nasazený image v Bailey nese soupis softwarových komponent (SBOM) a sken CVE běží nad tím imagem, který se skutečně nasazuje. Každý nález odkazuje na osv.dev, NVD a GitHub advisories.

Jaké role má Bailey a jak se liší?

Bailey má tři role, které vynucuje server: admin, auditor a member. Admin má všechna práva, member dělá každodenní práci se stavbou a nasazováním, ale nemůže měnit nastavení řízení, a auditor může všechno kontrolovat a spravuje nastavení řízení, ale nemůže nasazovat, povyšovat ani spravovat lidi, role, zařízení nebo administrátorská nastavení serveru.

Má auditor v Bailey jen přístup ke čtení?

Ne. Auditor v Bailey má v provozní lince jen přístup ke čtení, ale může nastavit, jak často se testuje obnova, a schvalovat záznam o zpracování podle GDPR pro odchozí server v produkci. Pravomoc nad souladem s předpisy tak zůstává oddělená od pravomoci nasazovat kód, a to je přesně oddělení povinností, které auditoři hledají.

Podporuje Bailey jednotné přihlášení (SSO) přes náš poskytovatel identit?

Ano. Admin Bailey může v sekci Admin konzole v části Single sign-on přidat libovolného poskytovatele OpenID Connect. Stačí zobrazovaný název, URL vydavatele (issuer) a client ID a secret. Skupiny od poskytovatele lze namapovat na role v Bailey. Bez mapování dostane každý roli member.

Může výpadek poskytovatele identit zablokovat administrátorům přístup do Bailey?

Ve výchozím nastavení ne, protože Bailey nechává vedle poskytovatele organizace dostupné i přihlášení účtem Bitswan. Pokud organizace účty Bitswan vypne, výpadek u jejího poskytovatele zablokuje přístup do konzole všem a operátor s přístupem k shellu na serveru musí spustit bitswan bailey sso disable, aby přihlášení přes Bitswan obnovil.

Stačí k přístupu do Bailey platné přihlášení?

Ne. Bailey je ve výchozím stavu zavřený: kdo se přihlásí z neznámého zařízení, neuvidí nic, dokud to zařízení neschválí admin. Ukradené heslo nebo kompromitovaný účet u poskytovatele identit použitý z počítače útočníka se proto sám nikam nedostane.

Jak Bailey schvaluje nové zařízení?

Nové zařízení zobrazí šestimístný kód, který server adminovi nikdy nepošle. Uživatel kód adminovi nadiktuje osobně nebo po telefonu, admin ho zadá do lišty „Device awaiting approval“ v People & roles a stiskne Trust this device. Jedním krokem tak uživatele zaregistruje a jeho zařízení označí jako důvěryhodné.

Co se v Bailey stane s neschválenými žádostmi o zařízení?

Bailey nikdy nepustí zařízení dovnitř automaticky a neexistuje ani rozhodnutí „zamítnout“, které by si musel pamatovat. Žádosti o zařízení, které žádný admin neschválí, prostě vyprší.

Jak rychle Bailey odřízne ztracený notebook nebo odcházejícího zaměstnance?

Okamžitě. Admin odebere zařízení (nebo celého uživatele) v People & roles a jeho přístup do konzole Bailey i do všech aplikací pracovního prostoru ihned skončí, bez měnění hesel napříč aplikacemi.

Kdo rozhoduje, kdo smí otevřít aplikaci nasazenou v Bailey?

Vlastník každého endpointu. Každý endpoint chráněný Bailey, včetně nasazených frontendů automatizací, dashboardů pracovních prostorů a gitops, je ve výchozím stavu zavřený. Jeho vlastník uděluje přístup konkrétnímu člověku podle e-mailu nebo skupině od poskytovatele identit na úrovni User nebo Owner a u každého udělení se zapíše, kdo ho udělil a kdy.

Umí Bailey posílat auditní záznam do našeho SIEM?

Ano. Bailey streamuje svůj bezpečnostní auditní záznam, včetně změn důvěry zařízení, změn rolí, zakládání pracovních prostorů a schvalování přístupů, do externího kolektoru přes OpenTelemetry protokolem OTLP/HTTP nebo OTLP/gRPC, volitelně s bearer tokenem. Do SIEM chodí také historie aktualizací a upozornění na překročení rezervované paměti.

Jak Bailey zabrání tomu, aby experimenty připravily produkci o paměť?

Každá automatizace v automation.toml deklaruje rezervaci paměti a politiku always-on, nebo on-demand. Služby always-on mají paměť zaručenou, služby on-demand sdílejí omezený fond. Při nedostatku paměti se vypínají od nejdéle nepoužité, dají se uspat tlačítkem Sleep a probudí se při prvním přístupu. Povýšení, které by se do rezervovaného rozpočtu nevešlo, Bailey odmítne a uvede přesný schodek.

Jak se v Bailey instalují a vracejí aktualizace?

Bailey označí zastaralé pracovní prostory i binárku serveru a každou z nich lze aktualizovat jedním tlačítkem v zobrazení Updates, bez práce v shellu. Každá aktualizace se zapíše i s tím, kdo a kdy ji provedl, a s přesnými verzemi. Roll back jedním kliknutím obnoví kteroukoli ze tří posledních zaznamenaných verzí a zapíše i samotný návrat.

Můžeme si při odchodu z Bailey odnést zdrojový kód?

Ano. Admin může pracovní prostor Bailey zrcadlit přes SSH do git repozitáře na GitHubu, GitLabu nebo Forgejo, který organizace sama spravuje, včetně kódu, specifikací, výjimek z CVE, manifestů nasazení a tagů historie nasazení každého firemního procesu. Zrcadlení je obousměrné a průběžné, takže odchod nevyžaduje žádnou součinnost poskytovatele.

Co Bailey udělá, když se náš zrcadlený git repozitář rozejde?

Bailey nikdy sám neudělá force-push do main. Pokud main na vzdáleném repozitáři už nejde posunout fast-forwardem nebo pokud příchozí změna způsobí konflikt, zrcadlení main se zastaví, Bailey vyjmenuje dotčené procesy a admin zvolí buď Force push to repair (opravit force-pushem), nebo Pause the remote (pozastavit vzdálený repozitář).

Slovníček pojmů

• Role admin: Role v Bailey, která má na serveru všechna práva, včetně nasazování, správy lidí, rolí a zařízení a administrátorských nastavení serveru.
• Dílna pro AI aplikace: Název, kterým BitSwan označuje svou kategorii produktů (AI application workshop). Je to řízené místo, kde lidé z firmy vlastními slovy popíší, co potřebují, a AI programovací agent napíše skutečný software, který běží na infrastruktuře firmy.
• Záznam, do kterého jde jen přidávat: Auditní historie Bailey (append-only log) se všemi sestaveními, žádostmi o odchozí spojení, schváleními, podpisy a nasazeními. Nepřepíše ji ani provozovatel a pro auditory se dá vyexportovat.
• Auditní kopie: Kopie přesně toho zdrojového kódu, ze kterého se zmrazený image sestavil (audit copy). Auditor v ní v Bailey čte kód a píše auditní zprávu.
• Politika auditu: Nastavení Bailey (audit policy), kolik podpisů auditorů (aspoň jeden) zmrazený image potřebuje, než se odemkne Promote to Production.
• Role auditor: Role v Bailey, která může všechno kontrolovat a nastavovat řízení (jak často se testuje obnova, schválení záznamu o zpracování podle GDPR pro odchozí server v produkci), ale nemůže nasazovat, povyšovat ani spravovat lidi, role, zařízení nebo nastavení serveru.
• Bailey: Soukromé běhové prostředí BitSwan s řízeným přístupem, které patří zákazníkovi. Běží v něm všechno, co v BitSwan vznikne, a řízení přístupu, auditní záznamy, zapečetěné tajné údaje i oddělená prostředí má zabudované.
• Blue-green přepnutí: Mechanismus povýšení v Bailey (blue-green cutover): nečinný slot se spustí nad živou databází, ingress se přesměruje na něj a starý slot se vyřadí, a to bez výpadku.
• Broadway: Metafora BitSwan pro cizí cloud (pravidla dodavatele, strop no-code nástrojů a data, o kterých nevíte, kde jsou), v protikladu k Bailey, které patří zákazníkovi.
• Firemní proces: Jednotka, která se v Bailey staví, nasazuje a provozuje (business process). Vzniká s backendovou a frontendovou automatizací a má vlastní kód, prostředí, tajné údaje, zálohy a firewall.
• Coding Agent: AI programovací agent, který běží uvnitř Bailey v izolované kopii uživatele, staví automatizace podle specifikace a k produkčním datům se nedostane.
• Odchozí provoz ve výchozím stavu zakázaný: Pravidlo Bailey (default-deny egress), podle kterého se odchozí provoz z testovacího a produkčního prostředí dostane jen na servery, které IT výslovně schválilo. Každé schválení se zapíše.
• Ve výchozím stavu zavřeno: Princip Bailey (deny-by-default), podle kterého žádný člověk ani zařízení nedostane přístup a žádný endpoint není dostupný, dokud to někdo výslovně neschválí nebo nenasdílí.
• Deploy: Akce v Bailey (nasadit), která commitne rozpracovanou práci firemního procesu, posune na ni main fast-forwardem a nasadí ji do vývojového prostředí.
• Deploy this version, overwriting main: Jištěná volba v Bailey (nasadit tuto verzi a přepsat main), po které main obsahuje přesně kopii uživatele. Předtím vypíše každý nahrazený commit a pro potvrzení vyžaduje název firemního procesu.
• Kód pro schválení zařízení: Šestimístný kód zobrazený na čekajícím zařízení (device approval code). Server Bailey ho adminovi nikdy neprozradí, takže ho uživatel musí nadiktovat jako důkaz, že je u toho.
• Důvěra zařízení: Řízení přístupu v Bailey vázané na hardware (device trust): přihlášený uživatel se nikam nedostane, dokud admin neschválí jeho konkrétní zařízení.
• DR slot: Izolovaný slot Bailey pro obnovu po havárii, do kterého se k ověření obnoví produkční záloha a který se přepnutím ingressu může stát živou produkcí.
• Edit this version: Akce Inspect v Bailey (upravit tuto verzi), která převede kopii uživatele na některou dříve nasazenou verzi pomocí obnovovacího commitu nad main.
• Endpoint access: Stránka konzole Bailey (přístup k endpointům), která vypisuje každý chráněný hostname za přístupovou bránou i s vlastníkem a pracovním prostorem.
• Sdílení endpointu: Mechanismus Bailey řízený vlastníkem (endpoint sharing), kterým se člověku nebo skupině od poskytovatele identit uděluje přístup k chráněnému endpointu na úrovni User nebo Owner. Každé udělení se zapíše.
• Experiment: Dočasná větev odvozená z osobní kopie uživatele v Bailey, omezená na jeden firemní proces. Dá se sloučit, převzít jako kopie, nechat běžet nebo zahodit, ale nikdy se z ní nedá nasadit do main.
• Freeze: Krok v Bailey (zmrazení), který v testovacím prostředí uzamkne přesnou verzi, aby se nezměnila, zatímco ji nezávislý auditor kontroluje a podepisuje.
• Zrcadlení do git repozitáře: Obousměrná funkce Bailey (git remote mirror), která přes SSH udržuje kód, specifikace, výjimky z CVE, manifesty nasazení a tagy nasazení pracovního prostoru v git repozitáři, který spravuje zákazník.
• Nezávislý poradce pro automatizaci: Jednotlivec s bezplatným veřejným profilem v Bailey, kterého BitSwan propojuje s firmami, jež chtějí automatizovat své procesy.
• Link a device: Akce v Bailey (propojit zařízení) v části Your devices, kterou důvěryhodný uživatel schválí nový prohlížeč zadáním šestimístného kódu, který prohlížeč zobrazil.
• Live-dev: Běžící náhledové nasazení, které Bailey dává každé automatizaci v kopii nebo experimentu a které se při změnách kódu samo znovu sestaví.
• Magic link: Odkaz v Bailey, který z dialogu Share produkčního endpointu vytvoří vlastník s rolí admin nebo auditor. Udělí prohlížeči důvěru jen pro tento jeden endpoint a nikdy nikoho nepřidá na jeho seznam přístupů.
• Role member: Role v Bailey pro každodenní práci se stavbou a nasazováním, bez práva měnit nastavení řízení. Výchozí role pro lidi, kteří přicházejí přes jednotné přihlášení (SSO).
• Politika rezervace paměti: Nastavení v automation.toml (memory reservation policy), které automatizaci v Bailey označí jako always-on (rezervovaná paměť, nikdy se nezastaví), nebo on-demand (výchozí; při nečinnosti se pozastaví a při přístupu probudí).
• Needs review: Seznam ve firewallu Bailey (čeká na kontrolu) s odchozími cíli mimo seznam, které čekají, až je uživatel schválí, nebo zamítne.
• Pool na vyžádání: Omezený fond paměti (on-demand pool), který Bailey dimenzuje podle několika největších služeb on-demand a ze kterého při nedostatku paměti vypíná služby od nejdéle nepoužité.
• People & roles: Stránka konzole Bailey (lidé a role) se seznamem lidí, jejich rolí a důvěryhodných zařízení, kde se zařízení schvalují a odebírají.
• Osobní kopie: Izolovaná větev pracovního prostoru, kterou Bailey automaticky vytvoří každému uživateli (personal copy). Probíhá v ní veškerá práce, dokud uživatel nestiskne Deploy.
• Promote: Krok v Bailey (povýšit), který posune verzi z vývojového prostředí do testovacího nebo z testovacího do produkce. Je povolený až po splnění požadovaných testů a u produkce navíc až po zmrazení verze a podpisu auditu.
• Proposed: Jediný stav požadavku v Bailey (navržený), který znamená „zatím není součástí zadání“. Běhy testů navržené požadavky přeskakují, dokud je někdo nepřijme.
• Recovery-tested: Označení v Bailey (obnova vyzkoušená) pro zálohu, která se skutečně nahrála do DR slotu a ověřila.
• Požadavek: Pravidlo firemního procesu v Bailey (requirement) vedené jako spustitelná kontrola v záložce Requirements & tests. Má ID AI-, pokud ho navrhl agent, nebo REQ-, pokud ho napsal člověk.
• Restore: Tlačítko v Bailey (obnovit), které jedním stisknutím vrátí produkci k předchozí podepsané verzi.
• Revert dev to this version: Akce Inspect ve vývojovém prostředí Bailey (vrátit vývoj na tuto verzi), která vývojové prostředí vrátí přidáním jednoho nového commitu do main. Ostatní ho převezmou při svém příštím Sync.
• Roll back: Akce v historii Bailey (návrat), která znovu nasadí image zaznamenané verze beze změny a zapíše nový záznam o návratu.
• Kořenové zařízení: Označení zařízení v Bailey (root device) pro prohlížeč, který si server převzal.
• SBOM: Soupis softwarových komponent (software bill of materials), který Bailey přikládá ke každému nasazenému imagi a který slouží pro sken CVE.
• Převzetí serveru: První přihlášení k novému serveru Bailey (server claim), při kterém operátor stiskne Claim this server, stane se kořenovým adminem a jeho prohlížeč se zaregistruje jako první důvěryhodné zařízení.
• Stínová AI: Výraz BitSwan (shadow AI) pro jakýkoli AI nástroj nebo software postavený s pomocí AI, který lidé ve firmě používají bez vědomí, souhlasu a kontroly IT.
• Stínové IT: Výraz BitSwan (shadow IT) pro neřízený software mimo dohled IT, kde data odcházejí bez kontroly, nikdo nic neprověřuje a do produkce stačí jeden prompt.
• Přeposílání do SIEM: Funkce Bailey (SIEM forwarding), která v reálném čase streamuje bezpečnostní auditní záznam do externího kolektoru OpenTelemetry protokolem OTLP/HTTP nebo OTLP/gRPC.
• Prostředí: Jedno ze tří prostředí, která má v Bailey každý proces (stage): Development, Staging nebo Production (vývojové, testovací nebo produkční). Každé má vlastní databázi, úložiště souborů a izolovanou síť Dockeru.
• Sync: Krok v Bailey (synchronizace), který přehraje práci uživatele nad commity, jež kolega publikoval do main. Jako záložka se zobrazuje jen tehdy, když je firemní proces pozadu.
• Důvěryhodná cookie: Přihlašovací údaj vázaný na zařízení (trust cookie), který zařízení v Bailey nese po schválení a díky kterému se uživatel může vrátit bez nového schvalování.
• Důvěryhodné zařízení: Prohlížeč, který Bailey zaregistroval a schválil (trusted device). Jeho cookie prokazuje hardware i přihlašovací údaje uživatele a dá se najednou zneplatnit v celé platformě.
• Evidence verzí: Záznam Bailey (version ledger) o každé aktualizaci serveru a pracovního prostoru s tím, kdo ji provedl, kdy a z jaké na jakou přesnou verzi. Zobrazuje se jako Update history a streamuje se do SIEM.
• Vibe coding: Stavění softwaru v chatu s AI, které se podle BitSwan děje všude, bez pravidel a bez škatulky.
• Výjimka z CVE (mimo rozsah): Záznam v Bailey v cve-waivers.yaml (waiver), který vyřazuje nález zranitelnosti a uvádí, kdo ho tak označil, kdy a proč.
• Pracovní prostor: Tematický, izolovaný prostor v Bailey (workspace) s vlastními firemními procesy, daty a seznamem členů, kde se rozhoduje o přístupech a rolích.

Kontakt a domluvení dema

BitSwan nabízí 30minutové demo v češtině nebo angličtině: ukáže Bailey, zájemce popíše, na čem pracuje, a obě strany společně zjistí, jestli je BitSwan pro něj vhodný. BitSwan demo popisuje jako „půl hodiny nad automatizacemi, které skutečně běží, bez prezentací a bez závazků“.

Co demo obsahuje.

• Živou prohlídku Bailey a automatizací, které běží v ostrém provozu.
• Proces samotného zájemce: BitSwan zájemce vyzývá „Přineste nám proces“ a ukáže, jak by ho postavil.
• Na přání projití kontrolního seznamu zájemce pro NIS2 nebo DORA bod po bodu přímo na běžící platformě.

Jak si demo domluvit. Tlačítko „Domluvit 30minutové demo“ na bitswan.ai si vyžádá telefonní číslo. BitSwan na ně pak zavolá a domluví termín.

Kontaktní údaje.

• Adresa: Pujmanové 1753/10a, 140 00 Praha, Česko.
• Obchod: sales@harmonum.ai.
• Program pro poradce a pomoc s profilem: support@bitswan.ai.
• Kontaktní osoby: Tomáš Doležal, CEO (tomas.dolezal@bitswan.ai, +420 602 273 468); Timothy Hobbs, CTO (timothy.hobbs@bitswan.ai, +420 773 501 238); Pavel Šolc, Business Development (pavel.solc@bitswan.ai, +420 737 239 890).

Weby.

• Anglicky: https://bitswan.ai/
• Česky: https://bitswan.ai/cs/
• Případové studie: https://bitswan.ai/cs/use-cases.html
• Bailey: https://bitswan.ai/cs/product-bailey.html
• NIS2 a DORA: https://bitswan.ai/cs/nis2.html
• Průvodce stínovou AI: https://bitswan.ai/cs/shadow-ai.html
• Srovnání: https://bitswan.ai/cs/compare.html
• Tým: https://bitswan.ai/cs/team.html
• Poradci: https://bitswan.ai/cs/advisors.html