AI-agent in productie meten: uitzonderingsratio, vrijgavetijd en herstel

De pilot liep goed. De agent verwerkte de proefbatch, de orderdesk keurde de voorstellen meestal goed en de demo leverde een overtuigend dashboard op. Dan komt de lastige vraag: mag je hem volgende maand twee keer zoveel werk geven?

Een totaalpercentage geeft daar geen antwoord op. Een agent kan 96 procent van de taken goed afronden en toch vier verkeerde ERP-writes veroorzaken. Of hij kan weinig fouten maken, maar elke uitzondering pas na drie dagen bij de juiste medewerker krijgen. Deze gids bouwt een productie-scorecard die zulke verschillen zichtbaar maakt en er een besluit aan koppelt.

De stap na een nulmeting, proefbatch en go/no-go voor een MKB-proces is dus geen groter model. Het is een vaste meetroutine per taaktype, periode en eigenaar.

Een productie-scorecard voor een AI-agent is een vaste set operationele metingen die per taaktype laat zien hoeveel werk de agent verwerkt, hoeveel uitzonderingen ontstaan, of de voorgestelde actie bewijs heeft, hoe snel een mens vrijgeeft, hoe lang herstel duurt en of de uiteindelijke systeemschrijfactie klopt. De scorecard is geen modelrapport. Ze is een besluitinstrument: opschalen, bijsturen of stoppen.

Wat je nodig hebt

Je hebt geen ingewikkeld onderzoeksplatform nodig. Je hebt wel een sluitende gebeurtenisketen nodig. Als je alleen de eindstatus completed bewaart, kun je later niet zien of een taak langzaam was door de agent, de menselijke wachtrij, het ERP of een herstelactie.

De bronnen en productdetails in deze gids zijn gecontroleerd op 13 oktober 2026. De NIST AI RMF 1.0 verscheen op 26 januari 2023, de EU AI Act Service Desk verwijst hier naar de geconsolideerde tekst van 27 juli 2026 en de OpenTelemetry-uitleg is van 14 mei 2026, laatst bijgewerkt op 14 september 2026. Prijzen en tooldocumentatie zijn op 13 oktober 2026 nagekeken.

Regel dit vóór je de productievolumes verhoogt:

• Een vaste taakdefinitie. Schrijf op wat één taak is en wanneer die begint en eindigt. Een verkooporder die uit e-mail komt is een ander taaktype dan een order uit EDI. Meng ze niet in één percentage.
• Een referentieperiode. Meet minimaal twee weken handmatig of in pilotmodus. Noteer volume, huidige behandeltijd, uitzonderingen en herstelwerk. Zonder nulmeting lijkt iedere automatisering winstgevend.
• Een eventmodel. Leg per taak een task_id, task_type, source_id, received_at, ready_for_review_at, approved_at, written_at, read_back_at, resolved_at, outcome en exception_code vast. Gebruik één tijdzone, bij voorkeur UTC in de opslag en lokale tijd in het scherm.
• Bewijs per veld. Voor een verkooporder zijn klant, artikel, hoeveelheid, eenheid, prijs en leverdatum geen losse modelvelden. Bewaar ook de bronpassage, record-ID, bronversie of berekening die elk veld ondersteunt.
• Een menselijke eigenaar. Benoem wie de uitzonderingsqueue behandelt, wie ERP-vrijgave mag geven en wie de wekelijkse beslissing vastlegt. Een gedeeld Slack-kanaal zonder eigenaar is geen operationeel proces.
• Een staginglaag. Bewaar het voorgestelde payload, de hash van de goedgekeurde versie en de status buiten de prompt. PostgreSQL, Supabase of een eigen kleine service werkt hiervoor beter dan een spreadsheet die tegelijk wachtrij, logboek en besluitregister moet zijn.
• Een uitvoerder met beperkte rechten. De agent mag voorstellen maken. Een aparte workflow of service controleert vóór de write nogmaals de status approved, de vervaltijd en de payloadhash.
• Een dashboard met doorsnedes. Toon minstens taaktype, bron, klant- of leveranciersgroep, modelversie, redencode en periode. Een gemiddelde over alle taken verbergt de plek waar het misgaat.
• Minimale rollen en kennis. Benoem een proceseigenaar die de taak en uitzonderingen kent, een technisch eigenaar die REST/OAuth, webhooks, idempotentie, SQL en read-back beheerst, en een review-eigenaar die bewijs controleert en ERP-vrijgave mag geven. Iemand moet daarnaast model- en promptversies, p50/p90 en foutclassificatie kunnen beheren. In een klein team mogen dit twee mensen zijn, maar geen van deze verantwoordelijkheden mag onbenoemd blijven.
• Een implementatiebudget. Als planningsorde op 13 oktober 2026, exclusief btw, modelverbruik en menselijke review, reken je voor ontwerp en eventmodel op €3.000-€8.000 eenmalig en voor één ERP-koppeling met staging, idempotentie, read-back en testen op €8.000-€25.000 eenmalig. Reserveer daarna €750-€2.500 per maand voor beheer, monitoring en incidenten. Menselijke review begroot je apart: bij 100-300 taken per maand, 5-10 reviewminuten per taak en een interne kostprijs van €45-€65 per uur is dat ongeveer €375-€3.250 per maand. Dit is een transparante begrotingsorde, geen offerte; toolabonnementen van enkele tientjes vervangen het ontwerp, de koppeling, het beheer of de reviewcapaciteit niet.

Voor de workflow kun je n8n of Make gebruiken. De actuele n8n Cloud-prijzen op 13 oktober 2026 zijn €20 per maand bij jaarlijkse betaling voor Starter met 2.500 volledige workflowuitvoeringen en €50 voor Pro met 10.000 uitvoeringen. n8n rekent een volledige workflowrun, niet iedere stap. Make rekent sinds 27 augustus 2026 met credits per moduleactie; de actuele Make-prijskaart toont Free tot 1.000 credits per maand, Core vanaf $12, Pro vanaf $21 en Teams vanaf $38 bij 10.000 credits per maand. Controleer bij aanschaf ook de gekozen factureringsperiode en valuta. Dit zijn orkestratiekosten, geen prijskaartje voor ontwerp, ERP-onderhoud of menselijke review.

Voor een menselijke poort kan de Wait-node van n8n hervatten na een tijdsinterval, webhook-call of formulierinzending. De resume-URL is uniek per uitvoering en kan met Basic Auth, Header Auth of JWT Auth worden beveiligd. Dat maakt hem bruikbaar voor de vrijgavetijdmeting, zolang de beslissing zelf in je stagingrecord terechtkomt en niet alleen in een bericht.

Voor traces van model- en toolaanroepen is OpenTelemetry bruikbaar. De GenAI-conventies leggen onder meer modelnaam, input- en outputtokens en toolaanroepen vast. Zet volledige prompts en toolresultaten alleen aan als je de privacy- en bewaartermijn beheerst. Voor de scorecard heb je meestal de metadata en een verwijzing naar het bewijsrecord nodig, niet een kopie van ieder klantdocument.

0/8

• Eén taakdefinitie per bron en procesvariant
• Minimaal twee weken nulmeting of pilotdata
• Timestamps van intake tot menselijke vrijgave en read-back
• Bronbewijs per verplicht veld en een unieke task_id
• Een eigenaar van de uitzonderingsqueue en een eigenaar van de vrijgave
• Een stagingrecord met payloadhash, status en vervaltijd
• Een beperkte ERP-write en een aparte read-backcontrole
• Een dashboard dat per taaktype en redencode kan filteren

Concrete stappen: van losse logs naar een besluit

Je bouwt de scorecard door eerst de taak en nulmeting vast te leggen, daarna zes kernmetingen uit één eventmodel te berekenen, uitzonderingen met bewijs te laten landen, de menselijke vrijgave en ERP-read-back te meten, en elke vaste periode een besluit te registreren. De volgorde is belangrijk. Een percentage zonder definitie is geen stuurinformatie.

1. Kies de meeteenheid en maak een nulmeting

Begin met één taaktype. Bijvoorbeeld: verkooporder_email_groothandel. Definieer:

• start: de oorspronkelijke e-mail of portalpayload is ontvangen en uniek geregistreerd;
• ready: het voorstel is compleet genoeg om door een medewerker te worden beoordeeld;
• released: een bevoegde persoon heeft de exacte payload vrijgegeven;
• done: het ERP-record is teruggelezen en de verplichte velden komen overeen;
• recovered: een fout of uitzonderingsitem is opgelost, afgewezen of bewust teruggezet naar handwerk.

Meet dezelfde definities eerst in de bestaande werkwijze. Vraag niet alleen hoeveel minuten een medewerker aan een order besteedt. Meet ook wachttijd, zoekwerk, correcties, dubbele invoer en de tijd die verloren gaat als een uitzondering bij de verkeerde persoon terechtkomt.

Splits per week op taaktype. Een agent die 80 eenvoudige orders verwerkt en 20 complexe portalorders krijgt een misleidend gemiddelde als je beide groepen samenvoegt.

2. Maak één scorecard met zes operationele maten

De kern van de scorecard ziet er zo uit:

De zes maten vullen elkaar aan. Volume zonder kwaliteit beloont meer werk dat later moet worden hersteld. Een lage uitzonderingsratio kan betekenen dat de agent te veel twijfelgevallen automatisch doorlaat. Een lage vrijgavetijd kan ook ontstaan doordat medewerkers blind goedkeuren. Lees daarom de redenencodes en steekproeven naast de grafiek.

De NIST AI RMF Playbook koppelt metrickeuze aan doel en gebruikscontext, vraagt om aanvaardbare grenzen en noemt meten vóór en na ingebruikname. Dat is geen voorgeschreven scorecard voor jouw proces. Het is wel een goede reden om jouw cijfers aan het concrete werk te koppelen, niet aan een algemene modelbenchmark.

3. Meet uitzonderingen als werk, niet als schaamtepercentage

Zet iedere uitzondering in een van tevoren gekozen redenklasse. Voor een verkooporder kunnen dat customer_ambiguous, item_ambiguous, price_expired, price_mismatch, insufficient_available_stock, delivery_date_unverifiable, duplicate_candidate en source_stale zijn.

Meet per redenklasse:

1. aantal en aandeel van het totale volume;
2. percentage dat de medewerker met één correctie kan oplossen;
3. p90 van de herstelduur;
4. de waarde of impact van de openstaande taken;
5. of de oorzaak in brondata, vaste regels, koppeling of modeluitvoer zit.

Een uitzonderingsratio van 18 procent is niet automatisch slecht. Als 16 procent bestaat uit een bewuste controle op nieuwe klanten en de queue binnen twintig minuten leegloopt, kan dat gezonder zijn dan 5 procent uitzonderingen die drie dagen blijven liggen. Stuur dus op reden, leeftijd en gevolg. Verander een legitieme goedkeuringspoort niet in een automatische doorgang om het percentage mooier te maken.

4. Maak bewijsvolledigheid toetsbaar

Een bewijsveld telt alleen mee als een medewerker het kan openen en de waarde kan terugvinden. Een modelconfidence van 0,98 is geen bewijs. Ook een link naar de oorspronkelijke e-mail is niet genoeg als de orderregel, prijsversie of ERP-match nergens is aangewezen.

Maak per taaktype een verplicht veldcontract. Voor verkooporder_email_groothandel kan dat zijn:

Rapporteer de volledigheid vóór de review en na correctie. Als medewerkers bijna ieder voorstel aanvullen, heb je geen hoge autonome kwaliteit. Je hebt een goed ingevulde reviewstap.

5. Meet vrijgavetijd en herstelduur als verdeling

Gebruik niet alleen een gemiddelde. Eén taak die vijf dagen wacht maakt een gemiddelde van veel snelle taken onbruikbaar. Rapporteer per taaktype p50, p90 en het aantal taken buiten de afgesproken grens. p50 laat de normale ervaring zien. p90 laat zien wat je proces op drukke of lastige momenten doet.

Meet de tijd vanaf ready_for_review_at, niet vanaf de eerste e-mail. Anders reken je de model- en wachttijd door elkaar en weet je niet welke knop je moet aanpassen. Bewaar ook de ruwe doorlooptijd vanaf intake voor de klantbelofte.

Meet herstel vanaf het moment dat de uitzondering is aangemaakt tot een aantoonbare uitkomst. resolved betekent dus niet alleen dat iemand de kaart heeft gesloten. Het betekent dat de taak is gecorrigeerd, afgewezen met reden, of bewust naar een handmatige route is overgedragen.

6. Maak de ERP-write één gecontroleerde stap

De vrijgave gaat over een bevroren voorstel. Controleer server-side opnieuw:

• is de menselijke goedkeuring geldig en nog niet verlopen;
• is dezelfde payloadhash goedgekeurd;
• zijn klant, artikel, prijs, voorraad en leverdatum nog actueel;
• is er nog geen ERP-record met dezelfde externe referentie;
• heeft de uitvoerder precies de benodigde rechten.

Schrijf daarna één keer. Bij een time-out is de status unknown, niet failed. Zoek eerst op de externe referentie, correlatie-ID of idempotente sleutel. Als het ERP-record bestaat, lees je het terug en koppel je de bestaande ID. Als het niet bestaat, herhaal je dezelfde actie met dezelfde sleutel. Een nieuwe sleutel kan een tweede order maken.

Lees minimaal de ERP-ID, klant, afleveradres, orderdatum, leverdatum, valuta, artikel-ID, hoeveelheid, eenheid, prijs, prijsbron en status terug. Een HTTP 201 of een groen workflowblok bewijst alleen dat de server antwoordde. Het bewijst niet dat het record inhoudelijk hetzelfde is als wat de medewerker zag.

Voor hoog-risico AI-systemen vraagt artikel 14 van de geconsolideerde EU AI Act om effectief menselijk toezicht, de mogelijkheid om uitvoer te negeren en een systeem veilig te onderbreken. Artikel 12 vraagt dat relevante gebeurtenissen automatisch kunnen worden geregistreerd gedurende de levensduur van het systeem. Artikel 14 behandelt het menselijke toezicht. Beide bepalingen staan in de EU AI Act Service Desk op basis van de geconsolideerde tekst van 27 juli 2026. De scorecard vervangt geen juridische classificatie, maar maakt de praktische bewijslast voor vrijgave en ingrijpen wel zichtbaar.

De recente gids over verkooporders uit e-mail en pdf gecontroleerd naar Exact Online laten gaan gebruikt dezelfde grens: eerst bewijs en staging, daarna één write en vervolgens read-back. Bij carrierclaims werkt het patroon ook voor carrier-events, claims en vervangzendingen met expliciete menselijke vrijgave. Bij financiële koppelingen moet je payouts, refunds en chargebacks apart reconciliëren vóór vrijgave, anders lijkt de operationele order goed terwijl de geldstroom nog openstaat.

7. Leg het ritme en de beslisser vast

Gebruik drie ritmes:

• Dagelijks: queue-eigenaars behandelen open uitzonderingen, verlopen voorstellen en onbekende writes. Dit is operationeel werk, geen strategische scorecardmeeting.
• Wekelijks: de eigenaar bekijkt per taaktype volume, exception rate, evidence completeness, p50 en p90 vrijgavetijd, p90 herstelduur, read-backpass en businesswaarde. De eigenaar legt één besluit vast met reden en actie.
• Maandelijks: operations en finance controleren of de nulmeting nog vergelijkbaar is, of de kosten en bespaarde uren kloppen en of nieuwe taaktypes dezelfde scorecard mogen gebruiken.

Vergelijk periodes met hetzelfde rooster en dezelfde taakmix. Een week met feestdagen, een nieuwe ERP-prijslijst of een andere inboxroute verdient een markering. NIST waarschuwt dat de geschiktheid van metrics kan veranderen door dataverschuiving, modelwijzigingen en een andere gebruikscontext. Een herijking hoort dus in het ritme, niet pas na een incident.

Valkuilen die je scorecard onbetrouwbaar maken

Je telt modelconfidence als kwaliteit

Een hoge confidence kan samengaan met een verkeerde klant, verouderde prijs of ongeldige leverdatum. Mitigatie: tel bewijs per verplicht veld, valideer tegen de bron en laat zakelijke regels buiten het model rekenen.

Je mengt taaktypes en bronnen

Een eenvoudige EDI-order en een vrije pdf hebben andere onzekerheden. Mitigatie: geef iedere variant een eigen task_type en vergelijk alleen gelijke groepen. Voeg pas samen als de denominators en regels echt hetzelfde zijn.

Je maakt uitzonderingen kunstmatig kleiner

Als medewerkers een twijfelgeval handmatig aanpassen zonder redenklasse, daalt je exception rate terwijl het probleem blijft bestaan. Mitigatie: een correctie is een meetbare uitkomst met reden, niet het bewijs dat de agent het goed deed.

Je gebruikt een gemiddelde voor vrijgavetijd

Een gemiddelde verbergt de achterstand die je klant het eerst voelt. Mitigatie: toon p50, p90 en openstaande leeftijd per taaktype en shift. Zet een expliciete eigenaar op items die buiten de grens vallen.

Je rapporteert read-back alleen bij succes

Een write die geen response geeft kan wel zijn uitgevoerd. Mitigatie: maak unknown een eigen status, zoek op correlatie en controleer het ERP voordat je opnieuw schrijft.

Je laat de mens te weinig context zien

Een knop met alleen Approve meet vooral klikgedrag. Mitigatie: toon bronpassages, gekozen record, berekening, uitzonderingsreden, payloadhash en vervaltijd. De bestaande mens-in-de-lus-werkwijze met goedkeuringspoorten per actie is hiervoor het ontwerpanker. Deze scorecard voegt de operationele vraag toe: hoe vaak werkt die poort, hoe snel en met welk herstelwerk?

Je schaalt na één goede week

Een kleine batch kan toevallig gunstig zijn. Mitigatie: gebruik een minimumvolume per taaktype, houd bij laag volume de limiet vast en kijk naar absolute aantallen. Twee goede perioden zijn een praktisch startpunt, geen statistisch bewijs voor ieder proces.

Je laat de scorecard een rapport worden

Een dashboard zonder besluit verandert niets. Mitigatie: voeg aan iedere periode een eigenaar, besluit, limiet, reden en terugkijkdatum toe. Geen besluit betekent dat je nog niet bestuurt.

Beslis-kader: wanneer opschalen, bijsturen of stoppen?

Gebruik onderstaande grenzen als startbeleid voor een agent met menselijke vrijgave. Ze zijn geen industrienorm en ook geen modelbenchmark. Kalibreer ze na je nulmeting, leg ze vast vóór je de productie verhoogt en maak de hardste veiligheidsgrenzen niet onderhandelbaar.

De grens nul dubbele ERP-writes is hard. Ook als het percentage klein is, kan één dubbel orderrecord de winst van honderden correcte taken wegvagen. Hetzelfde geldt voor een verkeerde prijs, verkeerde klant of onjuiste betaling. Een lage exception rate heft een veiligheidsincident niet op.

Businesswaarde bereken je per periode als:

(bespaarde minuten - reviewminuten - herstelminuten) × interne minuutwaarde - tool/modelkosten - foutkosten

Hier zijn bespaarde minuten de handwerkminuten uit de nulmeting die door de agentroute vervallen. Reviewminuten zijn de minuten voor menselijke controle en vrijgave; herstelminuten zijn de minuten tot een uitzondering aantoonbaar is opgelost, afgewezen of teruggezet naar handwerk. Foutkosten zijn de extra kosten in euro's die niet al in die herstelminuten zitten, zoals creditnota's, retour- of spoedtransport, claims, boetes, verkeerde downstream-mutaties en extra administratieve correcties. Tel dezelfde arbeidsminuten niet nogmaals als foutkosten. Gebruik voor de interne minuutwaarde een bedrag dat finance accepteert en schat foutkosten conservatief. Vergelijk met de nulmeting en toon het bedrag naast de operationele kwaliteit. Een agent die €400 per maand bespaart maar €1.000 aan foutkosten veroorzaakt, is geen positieve businesscase.

Voor de keuze tussen de drie uitkomsten kun je deze snelle route gebruiken:

Heb je per taaktype minstens 100 taken in de meetperiode en zijn de definities gelijk gebleven?

Nee, nog te weinig of te wisselendJa, de meetgroep is bruikbaar

Twijfel je tussen twee uitkomsten, kies de strengere. Een limiet later verruimen is eenvoudig. Een foutieve ERP-write terugvinden nadat downstream processen zijn gestart is dat niet.

Uitgewerkt voorbeeld: verkooporders voor een groothandel

Neem een groothandel die verkooporders uit e-mail en pdf laat voorbereiden voor Exact Online. De agent leest klantnummer, afleveradres, artikelcode, hoeveelheid, prijs en gewenste leverdatum. Een medewerker ziet bronbewijs en voorgestelde payload. Alleen na vrijgave mag een aparte uitvoerder de order schrijven.

Leg voor de implementatie de divisie, OAuth-rechten en responsevelden vast tegen de SalesOrders-referentie van Exact Online. De scorecard kan alleen een read-backpass berekenen als je vooraf bepaalt welke header- en regelvelden exact moeten overeenkomen.

De pilot heeft twee weken lang 260 orders verwerkt: 120 in week 1 en 140 in week 2. De nulmeting van de orderdesk was gemiddeld 7,5 minuten handwerk per order, exclusief wachten op voorraad- of prijsinformatie. Voor de productie-scorecard wordt verkooporder_email_groothandel als één taaktype gebruikt. EDI-orders blijven buiten deze meting.

In week 1 ziet de eigenaar. Voor de bewijsvolledigheid tellen zes verplichte velden per order mee: klantnummer, afleveradres, artikelcode, hoeveelheid, prijs en gewenste leverdatum. De noemer is dus 120 × 6 = 720 bewijsvelden. Er zijn 699 velden aantoonbaar onderbouwd en 21 velden ontbreken: 699 / 720 = 97,083...%, afgerond 97,1%.

Het besluit is niet opschalen. Hoewel het minimumvolume is gehaald, zijn de uitzonderingsratio, bewijsvolledigheid, vrijgavetijd en herstelduur niet groen; de write-route is wel goed. De eigenaar bevriest het daglimiet op 30 orders, laat de voorraadreden apart meten en verplicht bewijs van prijsversie en leverdatum vóór de review.

In week 2 verwerkt dezelfde route 140 orders:

Week 2 is de eerste groene periode, niet de tweede. Het minimumvolume is wel gehaald, maar de schaalregel vraagt twee opeenvolgende groene perioden. De eigenaar verhoogt daarom nog niet: het limiet blijft 30 e-mailorders per dag bevroren en week 2 wordt gemarkeerd als groene periode 1. Pas als week 3 onder dezelfde grenzen blijft, kan de limiet naar 45 e-mailorders per dag. De reviewfrequentie blijft wekelijks en de hogere belasting krijgt daarna een eigen markering.

De scorecard maakt ook duidelijk wat er niet mag gebeuren. Als Exact Online na een time-out een onbekende uitkomst geeft, gaat die order naar unknown. De uitvoerder zoekt op request_id en externe referentie, leest de bestaande order terug en maakt alleen een nieuwe write als er aantoonbaar niets bestaat. Als de prijsbron verloopt tussen goedkeuring en uitvoering, vervalt de payload en gaat de taak terug naar de queue. De oude goedkeuring is geen vrijbrief voor de voorraad en prijs van vandaag.

Dit is precies waarom de metrics per taaktype en periode moeten blijven bestaan. Een week met nieuwe klanten kan de exception rate verhogen zonder dat de agent slechter is geworden. Een nieuwe prijskaart kan de bewijsvolledigheid verbeteren en tegelijk meer menselijke prijsafwijkingen veroorzaken. De scorecard vertelt niet vanzelf welke oorzaak de juiste is. De redenklasse, het bronbewijs en de eigenaar doen dat.

Vergelijkingstabel: welke meet- en uitvoeringslaag past?

Productdetails en prijzen zijn gecontroleerd op 13 oktober 2026. Workflowprijzen veranderen; vergelijk bij aanschaf altijd dezelfde factureringsperiode en valuta.

De keuze volgt uit de zwaarste uitzondering. n8n of Make kan prima de intake, melding en wachtrij orkestreren. Zodra een verkeerde write financiële of operationele gevolgen heeft, hoort de bron- en statuslogica in een duurzame laag met expliciete rechten. Een kant-en-klare agentomgeving kan de eerste stap versnellen, maar koop geen dashboard als je nog niet kunt uitleggen wat één taak, één uitzondering en één geslaagde write precies betekenen.

De scorecard is pas klaar wanneer de laatste rij niet score heet, maar besluit. Na iedere periode moet zichtbaar zijn wie de limiet heeft verhoogd, welke redenklasse wordt aangepakt, welke fout tot stoppen leidde en wanneer je opnieuw kijkt. Een agent verdient meer werk niet doordat zijn gemiddelde groen kleurt. Hij verdient het doordat je per taaktype kunt aantonen dat bewijs, menselijke vrijgave, herstel en systeemuitkomst nog onder controle zijn.