АИ API Контроле потрошње за тимове: буџети, ограничења по кориснику, кључна ограничења и управљање трошковима

АИ API Контроле потрошње за тимове постају неопходне чим се употреба прошири изван једног кључа програмера и једног модела. Мали прототип може да ради на месечној фактури добављача и табели. Продукцијски тим обично не може. Када многи корисници, агенти, окружења, закупци, алати и провајдери деле исти буџет вештачке интелигенције, прави проблем није само разумевање рачуна након што стигне. Спречава ненамерну потрошњу пре него што постане инцидент, приписује трошкове правом власнику и намеће ограничења без изненађивања легитимног саобраћаја у производњи.

Добра контрола потрошње је систем, а не једно подешавање. Комбинује буџете, упозорења, чврста ограничења, ограничења стопе, правила по кориснику, правила по кључу, дозволе модела, аналитику коришћења и трајну књигу захтева. Провајдерске контроле могу бити довољне за једноставну примену. Буџети за обрачун у облаку помажу финансијским тимовима да прате широку потрошњу. Контроле на нивоу мрежног пролаза су често потребне када тимови желе доследне смернице за АПИ-је компатибилне са OpenAI, добављаче више модела, интерне кориснике, закупце клијената и токове посла препродавца.

Овај водич објашњава како функционишу контроле буџета АИ API, где се уклапају изворне контроле и контроле у облаку и шта да дизајнирате када вашем тиму затреба ЛЛМ API ограничења потрошње према кориснику, АИ API ограничења потрошње по кључу или шире управљање буџетом АИ модела у производном имању.

Коју АИ API контроле потрошње заправо контролишу

АИ API контроле потрошње ограничавају монетарну изложеност. Оне се разликују од обичних квота захтева. Ограничење брзине може дозволити 100 захтева у минути, али ти захтеви могу имати веома различите трошкове у зависности од модела, дужине контекста, дужине излаза, напора за размишљање, генерисања медија, хостованих алата, поновних покушаја, понашања кеширања и цене добављача. Десет кратких позива за класификацију и десет дугих покретања агента нису еквивалентни.

Контроле потрошње одговарају на питања као што су:

• Колико ова организација, пројекат, радни простор, тим, закупац, корисник, апликација или API кључ може да потроши овог месеца?
• Да ли треба дозволити захтев пре него што се пошаље узводно?
• Ко треба да буде упозорен на 50%, 80%, 90% и 100% буџета?
• Да ли систем треба да блокира саобраћај, врати моделе на старију верзију, паузира кључ или само обавести власника?
• Који модел, добављач, ток посла и корисник изазвали су пораст?
• Како треба да се снимају делимични стримови, неуспели позиви, поновни покушаји и усклађивање добављача?

Најјача имплементације третирају сваки захтев АИ као финансијски догађај. Захтев се одобрава, процењује, приписује, шаље, решава и касније усаглашава. То звучи теже од директног позивања модела, али то је разлика између контролне табле која објашњава јучерашњи дан и контролног авиона који може да спречи данашњи инцидент.

Упозорења, мека ограничења и чврста ограничења

Први избор дизајна је да ли ограничење треба да упозори, блокира или промени понашање.

Обавештења о потрошњи

Упозорења о потрошњи обавештавају праве људе када употреба пређе праг. Они су корисни јер чувају доступност. Производни радни ток наставља да ради док инжењеринг, финансије или операције истражују. Упозорења су прикладна за рано усвајање, ризик од некритичне прекомерне потрошње, коришћење истраживања и тимове који још увек морају да разумеју нормалну стопу сагоревања.

Слабост је очигледна: упозорења не намећу ограничење. Ако нико не реагује, или ако употреба расте брже од испоруке упозорења и одговора на инциденте, потрошња се наставља. Многи тимови откривају ово тек након што третирају упозорење о буџету као да је ограничење буџета.

Тврда ограничења потрошње

Тврда ограничења заустављају, гасе или на други начин спречавају додатно коришћење када се буџет потроши. Документација добављача обично описује чврста ограничења као враћање грешке када се примени. OpenAI документује организацију и месечна ограничења потрошње пројекта, са упозорењима која обавештавају и чврстим ограничењима која могу да врате 429 грешака. Такође напомиње да примена није тренутна, тако да забележена потрошња може мало да премаши конфигурисано ограничење. Цлоудфларе АИ Гатеваи документује ограничења потрошње заснована на трошковима која могу да блокирају са 429 када се премаше.

Тврда ограничења штите буџете, али стварају ризик доступности. Ако кључ који служи апликацији која је окренута клијенту достигне ограничење у подне, корисници могу видети грешке осим ако апликација нема резервну путању. За производне системе, тврдо заустављање треба да буде упарено са упозорењима о прагу, експлицитним руковањем грешкама, правилима на ниже верзије модела, хитним заменама или планираним режимом деградације.

Мека примена

Меке контроле се налазе између упозорења и чврстог блокирања. Примери укључују натписе упозорења, токове рада за одобрење за премиум моделе, привремене снижавања модела, смањена ограничења токена, ниже границе стопе или захтевање од власника да повећа буџет пре него што се ток посла настави. Меке контроле су корисне када тим жели да успори брзину сагоревања без прекида рада.

Опсими буџета: организација, тим, корисник, кључ, модел и закупац

Контроле потрошње су корисне само ако се опсег подудара са власништвом. Ограничење на нивоу организације је једноставно, али вам не говори који је тим изазвао проблем. Ограничење на нивоу корисника је праведно за људске алате, али можда неће одговарати налогу агента или услуге који делује у име многих корисника. Ограничење нивоа кључа је оперативно чисто само када су кључеви дизајнирани као границе смерница уместо заједничких тајни.

Уобичајени опсег буџета укључује:

• Организација или налог: Сигурносна мрежа највишег нивоа за укупну месечну изложеност.
• Пројекат или радни простор: Корисна граница када тимови производа, интерна одељења или пословне јединице имају засебну потрошњу.
• Окружење: Спречава развој, постављање или експерименте да троше производни буџет.
• Корисник: Добро ради за помоћнике за кодирање, интерне алате, истраживачке радне столове и апликације којима управљају људи.
• API кључ: Корисно када кључеви представљају апликације, станаре, клијенте, услужне налоге, окружења или токове посла.
• Закупац или клијент: Неопходан за СааС производе где многи клијенти користе АИ функције преко једне платформе.
• Класа модела или модела: Контролише изложеност скупим расуђивањима, видео записима, сликама, говору, дугим контекстом или рутама које захтевају много алата.
• Добављач: Помаже тимовима да одрже уравнотежену потрошњу између OpenAI-компатибилних добављача, облака или уговорених уговора.

Најбоља хијерархија је обично слојевита, али разумљива: глобално ограничење налога, ограничење тима или радног простора, ограничење окружења, ограничење кључа, ограничење за кориснике или закупца и ограничење специфично за модел где је потребно. Превише правила која се преклапају може отежати отклањање грешака у инцидентима. Ако организација, пројекат, кључ, корисник и модел ограничења враћају сличне грешке, оператери можда неће знати шта да покрену или ко је власник одлуке.

Ограничења потрошње по кориснику

ЛЛМ API ограничења потрошње према кориснику су најкориснија када људи директно утичу на коришћење. Примери укључују помоћнике за кодирање, радне просторе аналитичара, интерне алате за ћаскање, копилоте за подршку и истраживачка окружења. Без приписивања по кориснику, заједнички налог добављача претвара сваког корисника у део једног анонимног рачуна. Финансије могу да виде укупну потрошњу, али инжењеринг не може да каже да ли је скок дошао од напредног корисника, петље, нове функције или погрешно конфигурисане интеграције.

Контролама по кориснику је потребан стабилан идентитет. Сваки захтев треба да носи кориснички ИД или псеудонимни ИД крајњег корисника, плус тим, апликацију, окружење, ток посла и профил модела где је то могуће. Систем не мора подразумевано да складишти необрађене упите да би потрошња била одговорна. Потребно му је довољно метаподатака да одговори ко је шта потрошио, којим путем и према којој одлуци о политици.

Ограничења по кориснику нису увек права јединица. Позадинска услуга може деловати за многе кориснике. Агент може обављати посао који је покренуо један корисник, али проширен на многе задатке. Производу који је окренут клијенту можда ће бити потребна ограничења закупца више него индивидуална ограничења корисника. У тим случајевима, метаподаци корисника и даље би требало да буду забележени, али примарни буџет може припадати закупцу, апликацији или току посла.

Ограничења потрошње по кључу

АИ API ограничења потрошње по кључу су практична јер су API кључеви већ део путање захтева. Кључ може да идентификује радно оптерећење, закупца, клијента, окружење, програмера, партнера, налог услуге или површину производа. Када се кључеви третирају као ручице смерница, контрола потрошње постаје много лакша за размишљање.

Добар дизајн кључа избегава један дељени производни кључ за неповезана радна оптерећења. Заједнички кључеви краткорочно смањују административни посао, али слабе приписивање и одговор на инциденте. Ако сваки програмер, клијент и окружење користе исти кључ, пораст потрошње постаје истраживање евиденција, путања кода и времена уместо директног одговора на нивоу кључа.

Правила по кључу могу да примене месечне буџете, дневне буџете, дозволе модела, дозволе добављача, дозволе за руте, ограничења стопе и хитна замрзавања. Они такође подржавају чисте оперативне радње: замрзавање једног кључа клијента, смањење једног ограничења тока посла, ротирање једног компромитованог кључа или стављање у карантин једно окружење без утицаја на цео налог. За дубље смернице за дизајн, тимови често упарују ограничења потрошње са дисциплинованим API управљањем кључевима тако да кључеви представљају стварне оперативне границе.

Ограничења стопе у односу на ограничења потрошње

Ограничења стопа и потрошње решавају различите проблеме. Ограничава брзину контроле брзине: захтеви у минути, токени у минути, истовремени позиви или сличне јединице. Ограничења потрошње контролишу монетарну изложеност. Већини тимова је потребно обоје.

Ограничења брзине штите добављаче и апликације од рафала, олуја са поновним покушајем и неправедног коришћења ресурса. Они су добри у обликовању саобраћаја, заштити кашњења и спречавању да једно радно оптерећење потроши сву пропусност. Али број захтева је слаб заменик трошкова. Мали број позива за размишљање дугог контекста може коштати више од хиљада кратких довршавања. Генерисање медија, позиви алата, групни послови и петље агента чине јаз још већи.

Ограничења потрошње директно штите буџете. Они су посебно важни када избор модела, величина контекста, дужина излаза или алати могу да промене цену једног захтева. Подешавање за одрасле користи ограничења стопе за контролу облика саобраћаја и ограничења потрошње за контролу финансијске изложености.

Контроле на нивоу добављача, наплате у облаку и контроле на нивоу мрежног пролаза

Постоје три уобичајена слоја за АИ API управљање трошковима. Сваки има своје место.

Контроле изворне добављача

Изворна подешавања добављача су најједноставнија почетна тачка када тим користи једног добављача вештачке интелигенције. OpenAI документује месечна API ограничења потрошње на нивоу организације и пројекта, са упозорењима о потрошњи и тешким ограничењима потрошње. Anthropic документује на нивоу организације API ограничења потрошње и прилагођена ограничења потрошње и стопе за радне просторе; његова ограничења потрошње API разликују нулл као неограничену од нуле јер нема потрошње осим укључене употребе у документованим примерима.

Ове контроле су близу извора обрачуна и лако их је усвојити. Њихово ограничење је то што су специфични за провајдера. Ако тим користи неколико добављача модела, више облака, интерне мрежне пролазе или рутирање специфично за корисника, изворна подешавања добављача можда неће обезбедити један доследан приказ или један модел смерница.

Буџет за обрачун у облаку

Буџет за обрачун у облаку је драгоцен за тимове за финансије и платформе. Google Цлоуд Биллинг документује буџете ограничења потрошње за услуге које испуњавају услове, укључујући функције Gemini API, Агент Платформ, Цлоуд Рун и Цлоуд Рун. АВС смернице за Амазон Бедроцк описују коришћење профила за закључивање апликација са ознакама алокације трошкова, АВС буџетима, истраживањем трошкова, извештајима о трошковима и коришћењу, ЦлоудВатцх-ом и откривањем аномалија за праћење и управљање генеративном потрошњом вештачке интелигенције. АВС је такође најавио ознаке за расподелу трошкова за профиле закључивања Бедроцк апликације, помажући тимовима да категоришу употребу модела по одељењу, тиму или апликацији.

Буџети у облаку су јаки за широку расподелу трошкова и финансијске токове посла. Они могу бити мање директни за примену у времену захтева унутар апликације. Азуре АИ Фоундри документација о управљању трошковима каже да Азуре OpenAI тренутно не пружа чврста ограничења буџета у стилу OpenAI; Азуре буџети првенствено пружају упозорења, док аутоматизована примена захтева прилагођени развој. Азуре OpenAI квоте су такође ограничене на нивое претплате, региона, модела и типа примене, а не на нивоу закупца, што је битно када тимови очекују да се квоте мапирају директно на пословне кориснике или пројекте.

Контроле на нивоу мрежног пролаза

Контроле на нивоу мрежног пролаза се налазе у путањи захтева. Они могу да провере политику пре слања, приложе метаподатке, руту до провајдера, евидентирају коришћење и измире трошкове. Овај слој је посебно користан за OpenAI-компатибилне АПИ-је за вештачку интелигенцију и више провајдера јер апликација може да позове један управљани интерфејс док мрежни пролаз управља рачуноводством и смерницама специфичним за провајдера.

Цлоудфларе АИ Гатеваи документује ограничења потрошње заснована на трошковима која прате цену у доларима, а не број захтева, према моделу, добављачу или метаподацима као што су корисник, тим или апликација. Такође документује увиде корисника путем прилагођених метаподатака или Цлоудфларе Аццесс идентитета. У производу као што је Model Gate, исти општи образац мрежног пролаза је релевантан за обједињено обрачунавање, управљање кључевима API, аналитику коришћења, контроле тима, интеграције Telegram, повратне позиве, аутоматизацију партнера API и видљивост захтева/рачуноводства у више модела. Када проблем са обрачуном обухвата добављаче, мрежни пролаз може да постане практична контролна тачка за обједињену вештачку интелигенцију API наплату и примену смерница.

Шаблон имплементације: овлашћење, резервисање, отпремање, поравнање, помирење

Управљање буџетом модела робустне вештачке интелигенције је лакше када је животни циклус захтева изричит.

1. Овласти захтев

Пре слања саобраћаја узводно, проверите да ли су дозвољени кључ, корисник, тим, закупац, профил модела, рута и добављач. Authorization треба да садржи стање, месечни буџет, дневни буџет, дозволу модела, дозволу за руту и ​​провере ограничења стопе. Ово спречава очигледно неважеће позиве или позиве са прекораченим буџетом да стигну до добављача.

2. Процена или резервисање трошкова

За једноставне текстуалне позиве, груба процена може да користи модел цена, улазне токене, конфигурисани максимални излаз и позната подешавања алата. За радна оптерећења дугог контекста, мултимодалне, хостоване алатке, пакете и радна оптерећења агента, цена може значајно да варира пре него што постане позната коначна употреба. Неки системи резервишу буџет пре слања, тако да захтев не може да почне осим ако нема довољно преосталог износа. Резервација штити од прекомерне потрошње, али може да одбије захтеве који би се завршили јефтино.

3. Пажљиво шаљите и стримујте

Стримовање захтева посебно руковање. Коначна употреба може доћи тек по завршетку стрима. Корисници могу да прекину везу, провајдери могу да пропадну у току тока, а поновни покушаји се могу десити на неколико слојева. Гатеваи-у је и даље потребна утврђена евиденција коришћења. Ако се занемаре делимични стримови, извештаји о потрошњи ће бити погрешни. Ако се поновни покушаји наплаћују као неповезани захтеви, оператери могу пропустити појачавање поновног покушаја као основни узрок.

4. Решите стварну употребу

Након што добављач одговори, снимите стварне токене упита, излазне токене, кеширане токене, токене за образложење, трошкове алата, сликовне или аудио јединице, видео јединице, групне попусте, накнаде добављача и све друге наплативе димензије које провајдер излаже. Забележите тражени модел, решени модел, верзију цене, добављача, руту, одлуку о политици и статус захтева. Одвојите резервисана, овлашћена, решена, рефундирана, неуспела и помирена стања тако да делимични неуспеси не покваре аналитику.

5. Помирите касније

Књига захтева би требало да буде оперативни извор истине, али је и даље потребно усаглашавање са подацима о обрачуну добављача. Усклађивање хвата промене цена, прилагођавања на страни провајдера, одложено коришћење, недостајућу коначну употребу у стримовима и рачуноводствене разлике. Без тога, контролне табле могу да одступе од фактура. Уз то, тимови могу да верују и контролама у реалном времену и финансијским подацима на крају месеца.

Метаподаци о атрибуцији: основа корисних контрола

Контроле потрошње не успевају када су захтеви анонимни. Сваки захтев треба да носи стабилне идентификаторе који чине употребу објашњивим без излагања осетљивог садржаја. Корисна поља обухватају закупца, корисника, кључ API, тим, окружење, апликацију, ток посла, псеудоним модела, тражени модел, решени модел, добављача, центар трошкова и верзију смерница.

Ови метаподаци омогућавају повраћај средстава, откривање аномалија, наплату купаца, власништво над буџетом, реконструкцију инцидента и анализу производа. Такође чини контролне табле функционалним. Занимљив је графикон који каже да је потрошња удвостручена. Графикон који каже да је потрошња удвостручена јер је један ток посла пребачен са стандардног профила модела на модел премијум резоновања је оперативно користан. За тимове који граде интерну видљивост, контролна табла за аналитику коришћења АИ API треба да приказује потрошњу према кључу, кориснику, моделу, добављачу, тиму и временском периоду, а не само збирне укупне вредности.

Профили модела, алиаси и контролисана деградација

Апликације треба да избегавају расипање необрађених ИД-ова премиум модела по базама кодова. Контроле потрошње боље функционишу када апликације позивају управљане профиле модела или псеудониме као што су подразумевано ћаскање, резиме подршке, преглед кода, премијум резоновање или групно издвајање. Профил може да дефинише дозвољене добављаче, резервни редослед, ограничења токена, дозволе алата, смернице контекста и понашање буџета.

Ово је важно током притиска на буџет. Тим може да одлучи да очува доступност тако што ће смањити некритичан ток посла након 90% потрошње буџета, док ће премијум модели остати доступни за критичну путању производње. Надоградња модела може смањити трошкове, али такође може променити квалитет, кашњење, дужину контекста, понашање алата и очекивања корисника. Требало би да буде изричито у профилу модела и видљиво у књизи.

Контроле на нивоу модела су посебно важне за скупе моделе закључивања, позиве дугог контекста, генерисање слика и видео записа, хостоване алате и експерименталне руте. Тим може да има великодушна ограничења на обичне текстуалне моделе док захтева одобрење или мањи буџет за скупе часове.

Откривање аномалија и одговор на инцидент

Буџети су статични. Инциденти коришћења су динамични. Тимови би требало да прате стопу сагоревања и понашање, а не само кумулативну месечну потрошњу.

Корисни сигнали аномалија укључују појачавање поновног покушаја, петље агента, проширење излазног токена, регресије кеш-промашаја, изненадне промене рутирања модела, промене цене добављача, неуобичајену потрошњу по кориснику, скокове на нивоу закупца, експлозије позива алата и прелазак са групне употребе на коришћење у реалном времену. Ови сигнали би требало да покрену упозорења пре него што се достигне ограничење.

Хидне радње треба да буду једноставне, обимне и ревидиране. Оператори ће можда морати да замрзну кључ, смање ограничење тима, онемогуће профил модела, пређу на јефтинији резервни, блокирају закупца, паузирају ток посла агента или подигну привремено заобилажење. Систем треба да забележи ко је променио ограничење, зашто, када истиче и на који саобраћај је утицало. Хитне замене које нису документоване или никада нису враћене постају ризик другог трошка.

Платформе за партнере, продавце и клијенте

Контроле потрошње постају важније када платформа излаже приступ вештачкој интелигенцији клијентима, агенцијама, препродавцима или нижим апликацијама. У том случају, један налог провајдера може индиректно да служи многим предузећима. Један дељени кључ провајдера није довољан. Сваком клијенту или партнеру је потребна граница за буџет, коришћење, опозив, извештавање и усаглашавање.

Практичан образац је издавање кључева или група мрежног пролаза у опсегу корисника, додавање ограничења тим кључевима и аутоматизација операција животног циклуса путем API. Партнерским платформама ће можда бити потребни повратни позиви за промене стања, прагове потрошње, суспензију кључа, извоз коришћења и наплату клијената. Овде контроле пролаза и аутоматизација партнера API постају оперативне, а не административне функције.

Уобичајене грешке које треба избегавати

Најчешћи квар је један дељени кључ за све. То чини рани развој лаким, а каснију одговорност болном. Када се употреба повећа, нико не може брзо да идентификује да ли је узрок био клијент, програмер, окружење, промена модела, петља за поновни покушај или компромитована интеграција.

Још једна уобичајена грешка је мешање упозорења са великим словима. Алертс информ; строге границе примењују. Ако производни ризик захтева тешко заустављање, апликацији је потребна путања грешке. Генеричко необјашњиво 429 није довољно. Одговор треба да назначи које је ограничење достигнуто, на који обим утиче и време ресетовања ако је познато, без цурења неповезаних података о налогу.

Тимови такође потцењују варијацију трошкова. Број захтева и токена нису увек довољни када добављачи наплаћују кеширане токене, токене за образложење, алате, генерисање слика, аудио, видео, групне послове или јединице специфичне за провајдера. Сажимање свих наплата у генеричку цену токена чини буџете нетачним, а истраге спорим.

Коначно, многи тимови се ослањају на податке о фактурама као једини извор истине. Фактуре су неопходне за финансије, али стижу прекасно за оперативну контролу. Књига на нивоу захтева је оно што инжењеру омогућава да открије инциденте током месеца и реконструише оно што се догодило након тога.

Како Model Gate одговара

Model Gate је релевантан када тим жели OpenAI-компатибилан приступ вишеструким моделима са обједињеним обрачуном, API-управљањем кључевима, аналитиком коришћења, контролама тима, Telegram интеграцијама, повратним позивима и могућностима партнера API. У контексту контроле потрошње, важна архитектонска улога је капија: једно место за управљање кључевима, посматрање употребе, захтеве за атрибутима и примену тимских или клијентских смерница у свим моделима приступа.

То не уклања вредност изворних ограничења добављача или буџета за обрачун у облаку. То остају корисне сигурносне мреже и финансијске контроле. Слој мрежног пролаза је највреднији када је тиму потребна доследна видљивост и смернице у време захтева за неколико модела, корисника, кључева, тимова или налога клијената.

Контролна листа за АИ тима API контрола потрошње

• Дефинишите хијерархију буџета пре инцидента: организација, тим, окружење, кључ, корисник, закупац, модел и добављач.
• Дизајнирајте API кључеве као ручке смерница, а не само као тајне.
• Приложите стабилне метаподатке захтева за корисника, закупца, кључ, тим, окружење, ток посла, профил модела, тражени модел, решени модел и добављача.
• Користите и ограничења стопе и ограничења потрошње.
• Додајте упозорења о граничним вредностима пре чврстог заустављања, као што су 50%, 80%, 90% и 100%.
• Примените провере пре отпреме за стање, буџет, дозволу модела, дозволу за руту и процењене трошкове.
• Забележите одвојено резервисана, овлашћена, решена, неуспела, рефундирана и усаглашена стања.
• Изричито управљајте стримовањем, поновним покушајима, отказивањима и делимичним неуспесима.
• Користите профиле модела или псеудониме за контролисано рутирање и понашање на старију верзију.
• Направите контролне табле које приказују потрошњу према кључу, кориснику, моделу, добављачу, тиму, закупцу и току посла.
• Креирајте ревидиране радње за хитне случајеве за замрзавање кључа, смањење ограничења, онемогућавање модела, блокирање станара и привремено заобилажење.
• Ускладите употребу на нивоу захтева са подацима о обрачуну добављача или облака.

Закључак

АИ API Контроле потрошње за тимове су нешто више од постављања месечног ограничења. Издржљив систем комбинује власништво над буџетом, примену времена захтева, метаподатке о атрибуцији, ограничења по кориснику и кључу, аналитику, откривање аномалија и јасан пут одговора на инциденте. Упозорења помажу тимовима да рано интервенишу. Чврста ограничења штите буџете када је ризик неприхватљив. Ограничења стопа обликују саобраћај, док ограничења потрошње контролишу финансијску изложеност.

За тим са једним добављачем, подешавања изворног добављача могу бити довољна за почетак. За тимове који користе више модела, дељене интерне алате, функције вештачке интелигенције усмерене на клијенте или партнерске платформе, контроле на нивоу мрежног пролаза пружају доследнији начин управљања потрошњом међу корисницима, кључевима, закупцима, провајдерима и профилима модела. Циљ није блокирање корисног рада АИ. Циљ је да се коришћење учини одговорним, предвидљивим и контролисаним пре него што фактура постане прво упозорење.