Van wie is de sleutel? Als de AI in uw tools op het account van de leverancier draait

Een gebruiker van een gehoste automatiseringstool meldde op het communityforum van die tool dat een AI-videoworkflow na één upload vastliep. De workflow maakte korte video's met AI en plaatste die op het eigen kanaal van de gebruiker. De uploadstap gebruikte de kant-en-klare koppeling die de tool als aanbevolen markeerde, en het account stond als verbonden. De eerste video kwam online. De volgende upload mislukte met een foutmelding dat het quotum op was. De melding noemde een cloudproject dat de gebruiker niet in het eigen account kon vinden.

Een helper op het forum, geen medewerker van de leverancier, antwoordde dat het project hoort bij de app achter de kant-en-klare koppeling van de tool, en dat elke klant van de gehoste dienst die zo uploadt, het dagquotum van die app deelt. Toen wij de discussie lazen, hadden medewerkers van de leverancier dit niet bevestigd of ontkend. De helper stelde een tweede koppeling voor via een eigen cloudproject van de gebruiker, alleen voor de uploadstap, zodat het kanaal een eigen quotum krijgt.

De koppeling werkte. Ze was alleen niet van de gebruiker.

Gehoste tools maken de eerste dag makkelijk. U koppelt een dienst met één klik, betaalt modelaanroepen met de credits van de tool en laat de ingebouwde assistent de workflow bouwen. Achter elk van die gemakken zit een sleutel: een app-registratie, een API-key, een account bij een aanbieder. In een gehoste tool is die sleutel vaak van de leverancier.

Op de eerste dag is dat een eerlijke ruil. Dat verandert zodra een workflow echt werk doet. Met de sleutel van de leverancier krijgt u ook het quotum, de route naar het model, de modelkeuze en de kostentelling van de leverancier. Gaat er op die route iets mis, dan ziet u de foutmelding, maar de oorzaak ligt buiten uw bereik.

Dezelfde vraag geldt voor elke koppeling die een agent maakt; zie een AI-agent koppelen aan uw systemen.

Een gebruiker van dezelfde gehoste dienst meldde dat een agent die eerder goed werkte, nu vastliep bij de modelstap. Een webbeveiligingsdienst weigerde de toegang, en de blokkade noemde het domein van de leverancier. De agent bereikte het model via de gateway van de leverancier, betaald met de credits van de leverancier. Een helper op het forum raadde aan contact op te nemen met de support van de leverancier. Om intussen door te kunnen werken, stelde de helper voor om de modelstap om te zetten naar een eigen API-key van de modelaanbieder.

Een andere gebruiker meldde hoge dagelijkse kosten voor een persoonlijk project. De modelaanroepen in de workflows kostten weinig, zo legde de gebruiker uit. De kosten kwamen van de ingebouwde assistent van de tool, die elke dag urenlang werd gebruikt om workflows te bouwen en te herstellen. Die assistent draaide op een model dat de gebruiker niet kon wijzigen. Het tokenverbruik was niet te zien, en het tegoed van de assistent moest bijna elke dag worden aangevuld. Een tweede gebruiker schreef in dezelfde discussie dat het eigen creditverbruik voor het bouwen ook sterk was gestegen.

In een andere discussie meldde een gebruiker dat dezelfde assistent traag was, met de vraag of er een ander model te kiezen was. Een helper op het forum antwoordde dat de leverancier dat model bij de gehoste dienst beheert en geen wijziging accepteert, en dat een beheerder in een self-hosted installatie het model wel kan kiezen, met een eigen sleutel.

Een derde gebruiker twijfelde tussen de credits van de leverancier en een eigen sleutel, voor workflows die steeds dezelfde lange instructies meesturen. Op het forum vroeg de gebruiker hoe de gateway van de leverancier invoer afrekent die de modelaanbieder al in de cache heeft, en of die caching via de gateway überhaupt werkt. Een moderator van de leverancier antwoordde die kosten niet te kunnen bevestigen, en verwees naar support.

Telkens zag de gebruiker het gevolg: een foutmelding, een rekening, een trage assistent. De oorzaak lag op een route die niet van de gebruiker was.

Drie van deze discussies bevatten hetzelfde voorstel: gebruik een eigen sleutel of een eigen app. Dan zijn de limieten van de aanbieder de limieten van uw eigen account, en geen pot die u deelt met andere klanten van een tool. De rekening komt van uw aanbieder, dus u controleert de kosten bij de bron. Gaat er iets mis, dan regelt u dat rechtstreeks met de aanbieder.

In EpicStaff wordt het model per agent gekozen uit de modelinstellingen van uw organisatie, en voegt u de sleutel van de aanbieder zelf toe. EpicStaff draait op uw eigen infrastructuur; modelaanroepen gaan naar de providers die u instelt. Wat er nodig is om de rest van de stack zelf in handen te hebben, leest u in Zelfgehoste AI: zo houdt u uw AI-stack zelf in handen.

Een eigen sleutel maakt AI niet gratis en niet foutloos. U betaalt nog steeds voor elk token, en uw aanbieder kan nog steeds uitvallen of uw aanroepen beperken. U beheert nu ook een geheim. Bepaal waar het staat, wie het kan zien en wijzigen, en hoe u het vervangt als het uitlekt.

De rekening van uw aanbieder laat zien wat uw account verbruikte. Uw workflows, agents en stappen kent die rekening niet. Daarvoor moet de tool zelf het verbruik vastleggen, dicht bij het werk.

EpicStaff legt vast hoeveel tokens elke run gebruikte, en de sessie-export (JSON) bevat die. Het scherm van de lopende flow toont per bericht van een node het totale aantal tokens en het aantal prompttokens. EpicStaff schat daarnaast een bedrag in Amerikaanse dollars, op basis van de prijs die bij de modelinstelling is ingevuld of, als die ontbreekt, op basis van de openbare prijslijst. Het sessieverslag bevat het totaal, en stappen met een beslistabel tonen het op het scherm.

Hoe u de uitgaven van agents in beeld houdt, leest u in de kosten van AI-agents beheersen.

Neem de workflow die u het meest zou missen als hij morgen stopte. Volg hem van begin tot eind. Stop bij elke stap die een model of een externe dienst aanroept, en schrijf vier antwoorden op.

1. Van wie is de sleutel? Van u of van de leverancier. Is hij van de leverancier, kunt u dan overstappen op een eigen sleutel, en wat levert u daarbij in?
2. Van wie is het quotum? Als een limiet wordt gedeeld met andere klanten, kan een drukke dag elders uw werk stilleggen. Hoe zou u dat merken?
3. Welk model draait er, en wie kan het wijzigen? Neem ook de ingebouwde assistent mee als u daarmee bouwt. Een model dat u niet kunt kiezen, is een kostenpost die u niet kunt sturen. Wie beslist wanneer het model zelf verandert, leest u in Wie beslist wanneer het model achter uw agent verandert?
4. Waar ziet u tokens en kosten? Per stap, per run, of alleen op de maandrekening?

Een antwoord "van de leverancier" is geen fout. Het kan de juiste keuze zijn voor een proef, of voor werk dat een dag kan wachten. Het is een afhankelijkheid. Zodra die op papier staat, heeft ze een naam, en kan iemand er eigenaar van zijn.

De gebruiker uit de eerste melding koos de koppeling die de tool als aanbevolen markeerde. Die werkte, tot er een limiet werd bereikt bij een project dat niet in het account van de gebruiker stond. De vraag voor de eerste dag is kort: van wie is de sleutel?