Sigma Agents: firemní data jako řízený nástroj pro AI workflow

Firemní agent často narazí na stejný problém: umí napsat shrnutí, ale neví, která čísla jsou platná a kdo je smí vidět. Sigma Agents jsou zajímavé hlavně pro firmy, které už mají data a oprávnění uspořádaná v Sigmě a datovém skladu. Pro malý tým s jednou tabulkou bych kvůli této novince celou platformu nezaváděl.

Sigma 29. září 2026 oznámila obecnou dostupnost agentů. Nově je lze volat zvenku přes MCP a REST API. Téma pochází z doplňkové kontroly primárních zdrojů; článek publikujeme 30. září. Nejde o nový jazykový model.

Co se dá znovu použít

Podle dokumentace se agent váže na workbook, jeho instrukce, data a dostupné nástroje. Použití čerpá consumption credits. Důležitá je hranice mezi modelovým rozhodnutím a předem definovanou akcí: agent vybírá nástroj, samotná akce má konkrétní implementaci.

Pro CTO to znamená možnost soustředit definici pracovního úkolu na jednom místě. Obchodník může začít v AI chatu a interní pipeline přes HTTP, ale nemusí pokaždé znovu popisovat, jak se ve firmě počítá otevřená objednávka. Moje doporučení je přesto verze instrukcí evidovat a změny nejdřív zkoušet na kopii procesu.

Pilot: nesrovnalosti mezi objednávkou a fakturou

Nasazení bych navrhl takto; nejde o námi otestovanou integraci.

1. Vyberte jednu firmu nebo oddělení a omezenou sadu historických dokladů. Určete, které tabulky jsou autoritativní pro objednávku, přijatou fakturu a stav dodání.
2. Součty, měny a duplicity ověřujte deterministicky. Agent má vysvětlit rozpory a navrhnout další krok, nikoli odhadovat účetní pravdu.
3. Výsledek ukládejte do kontrolní fronty: ID dokladu, zdrojová data, důvod výjimky a návrh řešení. Člověk musí mít možnost otevřít původní záznam.
4. Teprve schválený výsledek předejte existujícímu n8n nebo Make workflow. Před zápisem ověřte aktuální stav a použijte jednoznačný identifikátor operace, aby opakovaný běh nevytvořil duplicitu.

Přesné schéma požadavku, autentizaci a zpracování odpovědi je nutné při implementaci převzít z aktuální API dokumentace. Dostupnost REST API není důkaz, že libovolný existující n8n node podporuje všechny agentní funkce.

Oprávnění otestujte dvěma účty

Sigma uvádí zachování datových oprávnění při volání agenta. To bych ověřil účtem běžného uživatele i účtem s širším přístupem na stejném dotazu. Test musí zahrnout cizí oddělení, chybějící doklad a pokus získat souhrn, který by mohl prozradit zakázaná data.

Oprávnění ke čtení a schopnost provést externí akci bych posuzoval zvlášť. Pilot nepotřebuje nástroj na schvalování plateb ani hromadné změny CRM. Měl by umět bezpečně skončit ve stavu „chybí podklad“.

Úspěch měřte na vyřešené výjimce

Sigma nabízí postup pro evaluační sady, včetně kontroly použitých nástrojů a správnosti odpovědi. To je dobrý základ, ale vlastní akceptační kritéria musí vycházet z firemního procesu.

Měřil bych podíl správně vysvětlených výjimek, falešné poplachy, minuty lidské kontroly a náklady na jeden schválený případ. Do nákladů patří vedle AI i dotazy do skladu, opakované běhy a provoz integrace. Obecná dostupnost neznamená bezplatný provoz ani připravenost vašeho datového modelu.

Největší přínos vidím tam, kde firma už důvěřuje svým datovým definicím a chce z analýzy přejít ke kontrolované akci. Bez této základny bude agent jen rychleji předávat nejasnosti z jednoho systému do druhého.

Zdroje: oznámení GA, Sigma Agents, evaluační sady.