Human-in-the-loop-patronen voor AI-agents in Jira

Human-in-the-loop is hoe je de controle behoudt terwijl agents meer van de build overnemen, en in Jira zit dit in de workflow in plaats van in een aparte tool. Teams die echt resultaten boeken, bewaren menselijk oordeel voor belangrijke beslissingen en laten agents de rest afhandelen.

Dat oordeel heeft een natuurlijke plek. Jira is de plek waar teams altijd werk hebben beheerd, en waar ze hebben goedgekeurd wat verdergaat. Nu geldt dat ook voor agents. Deze handleiding behandelt waar en hoe mensen de controle over AI-agents behouden, wie verantwoordelijk is waarvoor, en hoe je schaalbaar toezicht ontwerpt. Kortom, een goed ingericht human-in-the-loop-proces levert je drie dingen op:

• Goedkeuringen die acties blokkeren die je niet goed ongedaan kunt maken

• Beoordeling die uitvoer van lage kwaliteit of niet-goedgekeurde uitvoer opvangt voordat hij wordt geleverd

• Escalatie die onzekere aanroepen van de agent automatisch doorstuurt naar een mens

Wat is human-in-the-loop voor AI-agents?

Human-in-the-loop is een systeemontwerp waarbij een AI-agent pauzeert op gedefinieerde controlepunten, zodat een mens het werk kan goedkeuren, corrigeren of bijsturen voordat iets met grote gevolgen doorgaat. De agent zorgt voor de routinematige uitvoering, terwijl een mens de controle heeft over de beslissingen die echte gevolgen hebben.

Het is architectuur voor betrouwbaarheid, geen teken dat de AI heeft gefaald of een tijdelijke kruk die je weghaalt zodra het model goed genoeg is. De beste agentsystemen zijn systemen waarin menselijk beoordelingsvermogen precies daar zit waar het de uitkomst verandert.

In de praktijk komt human-in-the-loop meestal neer op drie patronen:

• Goedkeuring is akkoord vóór een risicovolle of onomkeerbare actie.

• Beoordeling is validatie van de uitvoer van de agent voordat die wordt geleverd.

• Escalatie is de overdracht door de agent als deze ergens niet zeker van is, context mist of merkt dat iets niet binnen zijn limieten valt.

Human-in-the-loop versus human-on-the-loop versus human-out-of-the-loop

Deze drie termen beschrijven hoeveel controle iemand behoudt zodra een agent aan het werk gaat. Het verschil komt neer op wie handelt en wie beslist.

Het doel is niet overal maximaal toezicht, of helemaal geen toezicht. Het doel is de juiste modus te gebruiken op basis van de werkelijke risicogebieden, en het vergroten van de autonomie van werk naarmate het vertrouwen groeit.

Waar behouden mensen de controle over AI-agents?

Begin met wie waarvoor verantwoordelijk is

Verantwoordelijkheid komt vóór het controlepunt. Voordat je bepaalt waar een mens beoordeling of goedkeuring uitvoert, bepaal je eerst waarvoor de agent überhaupt verantwoordelijk mag zijn. Het controlepunt is ter handhaving van die beslissing, niet ter vervanging ervan.

Een eenvoudige manier om het werk te verdelen, is op basis van hoeveel een fout zou kosten:

• Agent is verantwoordelijk hiervoor. Goed gespecificeerd werk dat de agent zelfstandig kan uitvoeren en afsluiten, zonder overdracht.

• De agent doet een voorstel, een mens beslist. Werk dat wordt opgesteld door de agent en wordt voltooid, goedgekeurd of teruggestuurd door een mens.

• Een mens is verantwoordelijk hiervoor. Haalt vanaf het begin een mens erbij, waarbij de agent ondersteuning biedt in plaats van beslissingen neemt.

De verantwoordelijkheid bepaalt wie het werk start, de bovenstaande toezichtmodi bepalen wie meekijkt zodra het in gang is gezet. In Jira is elke actie van een agent gekoppeld aan een bekende identiteit en komt die in de geschiedenis van het werkitem terecht, zodat verantwoording in de administratie is vastgelegd en niet afhankelijk is van het geheugen van mensen.

1. Goedkeuringen: aftekenen vóór werk met grote impact

Gebruik een goedkeuring wanneer een actie moeilijk ongedaan kan worden gemaakt. Productiewijzigingen, verwijderingen en kostenveroorzakende aanroepen horen allemaal pas plaats te vinden na aftekening, aangezien de kosten van een verkeerde stap hoog zijn. In Jira is goedkeuring een goedkeuringsstap in een workflow die een transitie tegenhoudt tot een met naam genoemde persoon hem aftekent, zodat de gate een onderdeel is van het proces, geen herinnering die iemand moet onthouden. Zie Richtlijnen en veiligheid van agentische engineering in Jira voor de volledige werking van workflowregels achter deze gates, waaronder voorwaarden en validators.

• In Jira: een agent bereidt een verandering met grote impact voor, bijvoorbeeld een update van een productconfiguratie of een release, en het werkitem kan de status goedkeuring pas verlaten als een benoemde goedkeurder akkoord geeft. Een native stap voor goedkeuring koppelt de transitie aan twee uitkomsten, goedgekeurd of afgewezen, en registreert op het werkitem wie de beslissing heeft genomen en wanneer.

2. Beoordeling: valideer de uitvoer voordat die wordt verzonden

Behandel uitvoer van de agent als niet-vertrouwd totdat je bestaande controles die hebben geverifieerd. Voor een coderingsagent is de beoordeling de pull request, die door je normale beoordelings- en samenvoegingsproces loopt.

Goed beoordelen betekent dat je het werk ziet, niet alleen het resultaat. De weergave van agentsessies op de Jira-pagina For You geeft je één plek om te zien wat een agent heeft gedaan en waarom, zodat beoordelaars met context beginnen in plaats van die opnieuw te moeten samenstellen.

• In Jira: wijs een werkitem toe aan een coderingsagent zoals de Jira Coding Agent. De agent leest het werkitem en de gekoppelde context en opent vervolgens een concept-pull request die is teruggekoppeld naar het werkitem, waar je die beoordeelt. Je beoordeelt die pull request via je gebruikelijke samenvoegingsproces, en de weergave met agentsessies op de Jira-pagina For You groepeert elke sessie op basis van wat vervolgens je aandacht nodig heeft en laat zien wat elke agent heeft gedaan, zodat je met context beoordeelt in plaats van die context opnieuw te moeten reconstrueren.

Wijs een Jira-issue toe aan de Coding Agent en zie hoe de agent je codebase verkent, de oplossing of feature schrijft en een pull request meldt, allemaal in een veilige cloud-sandbox.

3. Escalatie: draag over wanneer de agent het niet zeker weet of een issue buiten het bereik valt

Escalatie betekent dat de agent zijn eigen grenzen kent. Wanneer het vertrouwen laag is, context ontbreekt of een beleidsgrens wordt bereikt, moet de agent pauzeren en navraag doen of de issue doorsturen naar een persoon in plaats van te gokken. Het doel is om die overdracht systematisch te maken: ontwerp de triggers zo dat escalatie een uitzondering is die het systeem zelf meldt, niet een fout die een gebruiker achteraf moet opmerken. Vertrouw er niet op dat de agent de eigen zekerheid betrouwbaar kan beoordelen. Definieer de triggers zelf: ontbrekende vereiste context, een signaal met weinig vertrouwen waar er een bestaat, een wijziging boven een ingestelde grootte, of een actie die een beleidsgrens overschrijdt.

In Jira kunnen regels voor automatisering een opmerking toevoegen, een werkitem labelen met 'Moet verfijnd worden', of deze naar een persoon routeren wanneer context ontbreekt, en dit werkt op dezelfde manier, ongeacht of de agent van Atlassian of van een externe partij is. Wanneer een agent halverwege een taak moet pauzeren en iets moet vragen, wordt dit ingesteld in de eigen instructies van de agent (in Jira voor een Rovo- of Jira-agent), of in de configuratie van de externe agent voor tools (zoals Claude, Cursor of Copilot).

• In Jira: een automatiseringsregel verwerkt elke ochtend alle open beveiligingswerkitems en routeert op ernst. Risicoarme, omkeerbare oplossingen gaan naar een coderingsagent die een pull request opent. Alles met hoge urgentie of dat kritieke infrastructuur raakt, wordt samengevat en naar de juiste engineer doorgestuurd voordat er een verandering wordt doorgevoerd, zodat risicovolle beslissingen terechtkomen bij iemand die alle context al heeft.

Stel automatiseringen in Jira één keer in en je agents doen de rest.

Wanneer is human-in-the-loop een knelpunt en geen beveiliging?

Gebrekkig toezicht schiet op twee manieren tekort. Te weinig, en je levert niet goed afgestemd of onomkeerbaar werk: toen de acceptatie van coderen met AI toenam, stagneerden de productiviteitswinsten van developers rond de 10 tot 15%, omdat het schrijven van de code niet het moeilijke deel was van het leveren van software. Het gaat erom te bepalen wat je moet bouwen, het systeem te begrijpen waar je wijzigingen in doorvoert en te weten of de uitvoer veilig genoeg is om te leveren. Te veel toezicht en je schiet door naar de andere kant.

Human-in-the-loop wordt een knelpunt zodra de gates niet meer passen bij het risico. Drie foutmodi die vaak voorkomen, zijn:

1. Te veel gates. Als je elke actie controleert, krijg je controlemoeheid, zitten agents werkloos te wachten op een persoon en verdwijnt ongemerkt de snelheid waarvoor je agents hebt ingevoerd.

2. Goedkeuring zonder kritische beoordeling. Wanneer een gate wordt geactiveerd voor werk waarvoor deze niet nodig was, keuren mensen het goed zonder te lezen. Het controlepunt wordt een schijnvertoning en faalt precies wanneer een echt probleem erdoorheen glipt.

3. Aanwezigheid meten in plaats van toezicht houden. Het tellen van goedkeuringen laat je zien dat er een mens aanwezig was. Het betekent niet dat er iets is onderschept. Volume is geen oordeel.

Als je geen gate kunt maken voor elke actie zonder de doorvoer te verstikken, neem dan in plaats daarvan steekproeven. Beoordeel niet alles wat een agent verzendt, maar een deel ervan. In Jira kan een automatiseringsregel een percentage van door agents voltooide werkitems markeren zodat iemand ze kan controleren, of elk werkitem met hoge waarde doorsturen, zodat je de kwaliteit echt kunt bewaken zonder de voortgang te stoppen.

Jira als platform voor beoordeling en goedkeuring

In Jira is human-in-the-loop geen afzonderlijke tool, het is de omgeving waarin je team het werk al uitvoert, zodat elk controlepunt zich bevindt waar het werk al gebeurt. Dat is het verschil tussen toezicht dat schaalbaar is en een parallel controlevlak dat niemand onderhoudt.

De drie patronen komen samen op één oppervlak:

• Goedkeuren met een workflow-goedkeuringsstap die een transitie tegenhoudt totdat een genoemde persoon akkoord geeft.

• Controleer de pull request die is gekoppeld aan het werkitem, met de weergave van agentsessies op de Jira-pagina For You om te zien wat elke agent heeft gedaan en wat op je wacht.

• Escaleer via instructies voor agenten en automatiseringsregels, waarbij de overdracht en de persoon die verantwoordelijk is direct in het werkitem worden vastgelegd.

Jira maakt het gemakkelijk om de uitvoer van de agent te beoordelen en te beslissen wat wordt verzonden

Mensen en agents werken vanuit één bron van waarheid. De workflows, gegevensmachtigingen en geschiedenis waarop je team al vertrouwt, zijn van toepassing ongeacht welke agent het werk doet, zodat toezicht de controles hergebruikt die je al hebt in plaats van een tweede systeem dat speciaal voor AI is gebouwd. Je krijgt de checks zonder de wildgroei.

Best practices voor human-in-the-loop met AI-agents

De beste human-in-the-loop-systemen besteden menselijke aandacht waar die de uitkomst verandert en laten voor de rest agents het werk doen.

• Streef naar minder interventies met meer waarde. Elke gate brengt kosten met zich mee. Verwijder alles wat een formaliteit is geworden.

• Stem toezicht af op risico en omkeerbaarheid. Automatiseer routinematig werk. Bewaar goedkeuring voor wat duur is of moeilijk ongedaan te maken is.

• Scheid goedkeuring van beoordelingen. Goedkeuring vóór acties met grote impact, beoordeling van alles wat wordt uitgebracht.

• Maak escalatie systematisch. Definieer triggers vooraf: weinig vertrouwen, ontbrekende context of een beleidsgrens.

• Begin klein en breid daarna uit. Geef een nieuwe agent een beperkte scope en breid die gaandeweg uit naarmate de agent meer vertrouwen krijgt.

Zo stel je je eerste human-in-the-loop-workflow in Jira in

Je hebt geen redesign nodig om te beginnen. Kies één workflow, voeg één checkpoint toe en breid het van daaruit uit.

1. Kies één routinetaak. Begin waar een fout goedkoop ongedaan te maken is, zoals een verhoging van een afhankelijkheid, een oplossing voor een onbetrouwbare test of een update van documentatie. Bewaar het risicovolle werk voor wanneer je de configuratie vertrouwt.

2. Wijs dit toe aan een agent, beperkt tot die taak. Voeg de agent toe vanuit het veld uitvoerder, een bordkolom of een workflowtransitie. Deze handelt namens de persoon erachter, dus binnen Jira kan de agent alleen bereiken waar die persoon ook bij kan. Jira bepaalt de toegang tot je werk. Wat een externe agent met de eigen tools kan doen, wordt afzonderlijk ingesteld, buiten Jira om. Door de agent toe te wijzen, voer je het uit. Er wordt nog geen mens in de loop opgenomen, dat is het checkpoint dat je daarna toevoegt.

3. Plaats een checkpoint waar de impact terechtkomt. Bij de transitie naar een status met grote impact voeg je een goedkeuringsstap toe, zodat iemand goedkeuring geeft voordat het werk verdergaat. In abonnementen zonder native goedkeuringen gebruik je een transitievoorwaarde om te beperken wie het werk kan verplaatsen.

4. Stuur de uitvoer ter beoordeling. Laat de agent voor code een pull request opstellen die gekoppeld is aan het werkitem, zodat de verandering echt wordt beoordeeld voordat die wordt samengevoegd. Er wordt niets verzonden alleen omdat de agent dat zegt.

5. Bevestig het spoor en verbreed het daarna. Controleer of de acties van de agent zijn vastgelegd op het werkitem, en breid daarna uit: voeg eerst de volgende transitie, het volgende taaktype of meer scope toe aan omkeerbaar werk. Vergroot de autonomie naarmate de agent meer vertrouwen verdient.

Bekijk de acties die je agents hebben uitgevoerd en de beslissingen die ze hebben genomen in Jira.

Het endpoint is geen agent die zonder toezicht draait. Het is een workflow waarin mensen de beslissingen maken die ertoe doen, en verder niets, en elke stap wordt vastgelegd.

Klaar om mensen in de juiste loops te plaatsen? Begin met Jira voor AI-native ontwikkeling

Veelgestelde vragen over human-in-the-loop AI-agents

Hoe houd je een mens betrokken bij AI-coderingsagents?

Houd het werk van de agent controleerbaar en afgeschermd. Leid de uitvoer naar een pull request, vereis goedkeuring voordat ingrijpende veranderingen worden doorgevoerd, en ontwerp triggers zo dat de agent escaleert wanneer de agent iets niet weet of buiten de grenzen treedt.

Kunnen AI-agents in Jira menselijke goedkeuring vereisen?

Ja. Voeg een stap voor workflowgoedkeuring toe aan de transitie waarop impact terechtkomt. Het werkitem blijft wachten totdat een genoemde persoon goedkeurt of afwijst. Ingebouwde goedkeuringen zijn beschikbaar in de Premium- en Enterprise-abonnementen.

Wie is verantwoordelijk voor wat een AI-agent doet?

Altijd een persoon. De agent doet het werk, maar een mens is verantwoordelijk voor het resultaat. In Jira is elke actie van een agent gekoppeld aan een bekende identiteit en blijft die in de geschiedenis van het werkitem staan.

Wat is loop engineering voor AI-agents?

Loop engineering is het ontwerpen van de triggers die bepalen wanneer een agent zelfstandig blijft itereren en wanneer de agent het overdraagt aan een persoon. Goede triggers maken escalatie systematisch, zodat toezicht terechtkomt waar het risico zit, niet overal.

Voldoet human-in-the-loop aan de vereisten voor AI-governance?

Menselijk toezicht staat centraal in frameworks zoals de EU AI Act en NIST AI RMF, maar toezicht alleen is geen governance. Je hebt ook afgedwongen toegang, goedkeuringen en een audittrail nodig. Zie Richtlijnen en veiligheid voor agentgestuurde engineering in Jira.